Jeremy Huntwork wrote: > Ok, so we have a fair amount of items we'd like to push into 7.0, some > of which, work has already begun. > > As far as step-by-step plan of attack goes, how does this sound? > > 1. Move to DIY's new build method in trunk. If we ignore multilib and > any extra arch support for this step, the changes required aren't > actually that many, and they all take place pretty early in chapter 5. > We can have trunk using the new build method within a day.
That sounds fine to me. > 2. Add instructions for DESTDIR commands. I don't think there has yet > been a consensus yet on what type of PM to use. But, if we make the > instructions just slightly more PM friendly by adding in DESTDIR > commands it opens up a wide range of possibilities. If we limit the > changes now to just adding in DESTDIR commands and a short explanation > about what these mean somewhere or how to work with them, we should be > able to drop this into trunk in a short time (a day or two?). Otherwise > we may need a separate branch for PM. This is also good. IMO, trunk is fine. > 3. Merge all recent changes in trunk to the jh branch, copy that branch > to a new multi-arch branch and strip out anything extra that doesn't > really have to do with adding multiple archs. (I don't think there are > many, but I'd just have to do a quick look.) Hopefully making this its > own branch again would encourage a few more people to get involved in > finsihing up these changes. If desired, multilib support could also be > added to this branch. I'm not a big fan of branches. This would be fine for the trunk, but after the above two items are done and the changes have matured a bit. Do we have a solution for the boot loader for this? As a personal note, I guess I'll need to get a 64-bit system. I'm really still pretty happy with my current 3.2GHz/2G Ram. It almost never swaps and I use KDE and Vmware. I think my wife's system would work (it's an Intel 2160 with two cores) but she would not be happy. ... thinking about it, I don't think that's a viable solution. :) > 4. Ticket 2284, upgrade of Udev, and strip out udev-config. I doubt this > needs its own branch. What sort of time/work is involved here? Just do it. I don't think it will be a large time consumer. It could be done now. > 5. Ticket 2033. Include support for initramfs. Would this require a > separate branch, and can it be worked on in parallel to other changes, > or is it better to wait until other above changes are sorted out? This is one I don't agree with. This should be in BLFS. A pointer to a BLFS page in LFS would be OK, but this goes beyond the philosophy of LFS as it is only rarely needed. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
