On Wed, Nov 18, 2009 at 12:10 AM, Andy Grimm wrote: > I've taken some time today to look over the Fedora 12 anaconda bits. > As expected, some pretty massive changes since our F8-era snapshot > (literally tens of thousands of lines according to diffstat). here > are my thoughts on how to attack the update:
Yes they changed a lot, rewritten HW Probing, using autotools, different Filesystem handling... > 1) We should start testing with F12 bits in the templates first. > That will require some build tweaks in the beginning, since we won't > have these packages in "capsule" form, but that's not too difficult (I > might just build with cvc at first to save time). Not sure what you mean with 'testing in templates first'. > 2) In the first pass, my _only_ concern is to get a system installed > with the tarball installer, and with SELinux disabled. All other > changes (extlinux bootloader, conary installer backend, USB stick > install, etc.) can wait. Although extlinux/bootman is hight on the priority list too, but... current extliux doesn't support installing on ext4 yet, so until extlinux 4.0 arrives, we need to force /boot to be ext3. > 3) Every patch should be done in a way such that upstream _could_ > accept it. The idea is to add our features, not be a fork. Our > version of anaconda should still be able to install an RPM-based > distro if someone builds templates with the right modules (yuminstall, > rpmUtils) included. If that is doable, I'm all for that, I think tarball install could be interesting for fedora too. > Most of the changes that need to be done fall into a few categories: > > * script changes -- updates update-instroot, mkimages, etc. are where > the largest differences are by far. We may be able to leave out some > of this due to our build process changes I'm not sure what calls all these scripts. I wonder if it wouldn't be easier to leave the scripts untouched and create update-instroot-cny, .. and call that, or make the script source a update-instroot-cny if WITH_CONARY is set... trying to be as noninvasive as possible. > * inserting our own debugger -- changing "import pdb" to "import > debugger" and related lines, This is easy. > > * ignoring selinux & yum references. For SELinux, this is fairly > easy, but the installer assumes the use of yum in more places than it > used to. That would probably need some refactoring and abstraction upstream. > * making sure our backend and install classes are compatible with new > code. I don't think this will be much of a problem. I also think, that this (hopefully) is one of our smaller tasks. > I'm going to try to put together a version of templates here in the > next few days, and I'll let you know what happens... Thanks. > --Andy Mark -- Mark Trompell Foresight Linux Xfce Edition Cause your desktop should be freaking cool (and Xfce) _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
