On 05/20/2012 07:09 PM, Ken Moffat wrote: [putolin]
> 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 Just use the dependencies that are required that's in the book. You as a "user/builder can add any additional one you would like. > 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). pacman package management also has a set of tools to check the resulting package for "corectness" based upon LSB. It will also detect permission problems and RPATH issues. > > 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 ? One doesn't need to fetch a binary, just the PKGBUILD file and then you can build it > 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 I have placed my build of LFS 6.8 using Arch linux pacman package manager onto github. The URL: github.com/baho-utot/LFS-pacman Have a look at it if you like. I don't follow the recent comments at all. Pacman packeage manager has some great features that makes rooling your own easier. For example if I get the PKGBUILD for a package that is in BLFS from someone then I am not duplicating my effort and I have a mecanisim that gives me a "package that will work". Package management is also learned so why not include something in the book? I see using pacman package management as a plus. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
