[lfs-dev] Once more: Package Management

Ken Moffat zarniwhoop at ntlworld.com
Sun May 20 16:09:49 PDT 2012


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



More information about the lfs-dev mailing list