On Sat, May 19, 2012 at 09:26:31AM -0400, Jeremy Huntwork wrote: > > Proposal: > > 1. Adjust LFS/BLFS to auto-generate build recipes for individual > packages that a packaging tool can use to create binary packages with > meta information included such as dependency tracking. > > 2. Store 'official' copies of those binary packages in a developer > package repository so that when developing (primarily BLFS) a dev can > automatically pull and install into a build environment the dependencies > he needs to build and create an individual package. > > 3. Create a standard workflow and tools whereby a developer can > accomplish #2 and edit the book accordingly in an efficient, reliable way. > The more I think about this, the less happy I am. Point 2 doesn't really help editing BLFS as far as I can see (upgrading a package usually needs several builds - typically, for me, a first to see if it actually works when I use it, then others to get nice clean measurements, check what is in the DESTDIR (or INSTALLROOT), and review options for the optional dependencies and any testsuite.
OK, for a few packages I will build them without being able to confirm that they still work (e.g. mutt in the recent tagging), but in general the absence of required dependencies is the least of the issues - and anyway, sometimes the dependencies need to be upgraded. Then there is the question of dependencies - in BLFS we don't normally tell people how to use optional deps. Sometimes they are picked up automatically, but many times you have to pass a switch to get them used. The instructions in BLFS are hopefully correct, but they don't suit everyone. I'm also wary of standard workflows - my own LFS build is different enough (nothing updated in /sources, because that is an nfs mount on my systems, and with efforts to remove many of the static libraries) that I expect pain. And that's just for LFS. For BLFS, I suspect this sort of change will actually increase my workload and therefore reduce my contributions. > Rationale: > > (B)LFS-style development by hand becomes a huge undertaking. BLFS _is_ a > huge undertaking - and it's a difficult beast to maintain. In order to > create a stable reference page in BLFS an editor has to have spent the > time to build all of LFS, tweak it, go through current BLFS, manually > install dependency packages and then carefully document the package he > builds. No two developers are guaranteed to have the same environment, > either, so accuracy and stability becomes an issue. > Indeed. For BLFS, I'm typically now building on both the last LFS release, and also on a more recent svn version to make sure that when I say it builds and works with 7.1 it does, and to detect if any change in a newer LFS package has broken something along the way (nothing recent, but I can remember pain in a package from a grep update: something to do with manpages in a docbook package, I think, which only bit me some time later because I hadn't been building whichever package it was, and also problems caused by newer kernel headers). The intention is good, but I'm not at all convinced that the plan will help. Also, can I really trust whoever is permitted to edit a book (I'm assuming that part of the aim is to get more people editing in BLFS ?) to have an uncompromised system, and to not want to upload compromised binaries ? For the xml in the book, and for patches, we can look at what is being changed. For a binary, how do we know what was done to it ? Distros have build machines with restricted access and some degree of security. Is LFS going to need signed binaries and a ring of trust ? If I upload an unsigned binary package, the only way you can verify it is by following the build instructions and seeing if you get the same result. I gave up 'farce' testing (seeing if binaries were the same after an LFS system built itself) because there were too many inexplicable differences, probably caused by randomisation of addresses. Posts in the last few months have suggested that this problem is no longer present, but don't understimate the difficulties of trying to see if my binary build matches yours using the same instructions and the same versions of everything. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
