[lfs-dev] Once more: Package Management
baho-utot at columbus.rr.com
Sun May 20 17:57:50 PDT 2012
On 05/20/2012 07: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.
> 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.
>> (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
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.
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
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.
More information about the lfs-dev