Aiming for 7.0

[Bruce Dubbs]

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