[lfs-dev] Once more: Package Management

Baho Utot 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.
>> 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.

More information about the lfs-dev mailing list