Now my understanding of that doesn't include anything about
removing
custom partitioning. It's all about splitting up the functionality of
anaconda into two distinct parts - the GUI configuration part, which I
would expect still to contain custom partitioning, and a back-end that
implements the configuration, where the configuration is passed to it
in the form of a kickstart file (either the output of the GUI part, or
a kickstart file prepared earlier by the user).
This is basically correct, though I doubt the kickstart-based action is
going to be all that noticable to the user. From an implementation
perspective, it certainly is very appealing though.
My understanding is based entirely on Adam's description since
I'm not
involved in anaconda development, but it strikes me as being a good
thing as it would split one large process into two, presumably smaller
ones, which would help solve the problem of running anaconda on
machines with less memory.
The memory consumption was largely based upon merging the initrd and the
stage2 image into one very large initrd that had to be in memory.
However, we've made additional changes that split it back up (though,
not in an annoying way like it used to be) that means much less stuff
needs to be kept in memory.
- Chris