On 5/20/12 7:09 PM, Ken Moffat wrote: > 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.
Actually, from my experience a packaging tool eases a lot of the pain inherent in the process you've described. Auto-fetching of sources (including dependencies), auto-preparation of a clean build tree, post-build reports of what files have been included in the package and what (if any) auto dependencies have been discovered. Re-doing a build if issues or errors are found (including, if necessary, setting up an entire chroot system as well) becomes a matter of one command, instead of several. > 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. This is one of those scenarios where I think it's difficult to see how a thing will be useful or beneficial until after you've actually tried it out. I'm not guaranteeing you'll think it better, more useful or simpler - though my belief is that it does actually simplify the process of correctly building and documenting the build of an individual package, once the tools are available and the infrastructure in place. > The intention is good, but I'm not at all convinced that the plan > will help. Perhaps it really is something that needs to been seen and experienced. I can do as I planned and document the procedure to build in PM with LFS and set up the basic infrastructure required (a web server with a public binary repo). Once that's in place, anyone who wants to test out the new workflow can try it and offer thoughts, comments, suggestions. Then perhaps a decision can be reached as to whether it be actually implemented for either LFS or BLFS. This way, too, at least the documentation will have been done. Anyone interested in helping with the above, or should I just report back here when I've accomplished this on my own? > 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 ? This is a great question, and I'm still not sure the best way to answer it. Perhaps it should be tabled and reconsidered if and when either book looks to actually adopt the workflow as 'official'. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
