Dan Nicholson wrote: > My opinion: Making the build alphabetical is silly. It's a purely > cosmetic change that doesn't do anything for getting a better final > result. Checking that the order a package is built will alter the > final product is a worthy task and should be done. If in the end an > order can be made that doesn't alter the final product and can be made > alphabetical, then that's fine.
Once more, for the sake of clarity. The goal of the lfs-alphabetical branch was *not* solely to make the build alphabetical! (maybe I should have named it differently?) Anyone who still thinks so should go back and review the bug that started this research in the first place. The alphabetical order simply serves to structure and organize the packages where any random order will do and where all dependencies have already been met. It's more than just cosmetic. The real thrust behind this research is to have a rationale for each package -- *why* it's built *when* it's built. IMO, that's 10 times better than just saying 'eh, the build order is a huge mess, we don't know why this package is before this other one, but it works so let's just leave it.' Note, too that in the proposed branch and build order *all* dependencies will be listed - even the ones that are satisfied by the alphabetical order. Nothing will be unknown. Dan, I respect your opinion (and those of others that have already voiced similarly), but I just want to make sure that it is an opinion that is formed after having understood the incentive behind the suggestions. > Jeremy, I think that a better goal would be to resurrect the purity > tests and see how current LFS stacks up. I'll be glad to help on > this. I have slow hardware, so doing a complete LFS is an all day Sure. But I would rather do purity tests on the alphabetical. Current LFS is broken in that no one knows why things are done the way they are. It's a ridiculous position for this project to be in, really. > affair, and I can't completely devote my one box to this purpose. So, > I'll try to help where I can. Next month I hope to be getting a new > machine, so maybe my contribution could increase then. > > I think that if the current LFS passes, then we should look into > documenting the build order and changing it if it's possible. You're I still disagree. I think the *principle* of building LFS, ie, build a sane toolchain and default tools, chroot, build the final toolchain and final tools is set and working - but nearly everything else is an unknown. It's time to start from scratch as it were and re-evaluate the whole thing and *then* test for purity, because only then will we *know* what we're dealing with and only then will we have an answer for everything we do. Current LFS trunk can fend for itself. > Ken's farce tool seems like it will do the diffing for you, but I'm > not familiar with it. However, I'm much more familiar with Greg's > gsbuild system. You can get the current one at > http://www.diy-linux.org/downloads/contrib/greg_schafer/gsbuild/gsbuild-20050825.tar.bz2 > > It can be a bit much to swallow at first because he makes extensive > use of variables and functions. Look at the file common_sh.functions > file at the bottom to see the ICA functions. > > Let me know what you think. I've been seriously thinking about doing > this for a while now, and I'm trying to get my scripts in shape to > automate it. Essentially, this means I'll be ripping off gsbuild :) > (Thanks in advance, Greg.) All these suggestions sound fine, and if you want to do it against current trunk, go right ahead. I think the real effort needs to be done against a new build order. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
