Bruce Dubbs wrote: > Jeremy Huntwork wrote: >> 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.
No objections so far, and a couple of encouraging comments, I'll start on this one now. >> 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. OK, once I finish with the above, we can open this up as a ticket to bring all packages into compliance. This could probably benefit from a few different hands/eyes. >> 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? OK. I assumed we'd want to get the boot loader stuff fixed up first. (No, it's not done yet.) The solution really amounts to: add lilo or grub2 for use by Non-multilib x86_64. Multilib x86_64 could obviously still make use of grub legacy. If we want to officially support PowerPC on new-world Macs (the current instructions in the jh branch do work for these) we'd have to add Yaboot for them. But if we're taking it as a separate ticket that we will be adding in a proper bootloader I could just go ahead and merge the jh branch back to trunk. > 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. Yep. This is Matt and Bryan's arena. >> 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. Well, I'll let the rest of you sort this one out as I can't say I have a strong opinion either way. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
