> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
