Aiming for 7.0

[Jeremy Huntwork]

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