[lfs-dev] Once more: Package Management

Jeremy Huntwork jhuntwork at lightcubesolutions.com
Sat May 19 12:24:28 PDT 2012

On 5/19/12 1:15 PM, DJ Lucas wrote:
> What separates LFS from say Arch, Gentoo, T2... at that point? No mile
> long USE flags or complex switching scripts I presume, but I know little
> about the other two. I've included some of their work in BLFS in the
> past, but that is about it.

Well, the way I saw this working out in my head - we don't really 
advertise the binary package repository, although it would be available 
for anyone to use. Hence, "semi-public". The focus would still be on the 
book and letting a user choose her own path. The optional PM parts would 
serve as a reference for how to do something similar either with the 
same packaging tool, or one of the user's choice.

And yet, in the background, what I'll call the "distro-y bits" would be 
fully functional, driving consistency in the book(s) as well as accuracy 
since it should serve to help identify dependencies and installed 
resources. If anyone chose to actually use the created and shared 
binaries as a full-fledged distro, they absolutely should be able to, 
with the knowledge that we are not providing any guarantees as to 
usability, reliability, or support, etc.

> My hope is that build order is still a manual process where the user
> determines build order herself. Dependency checking is done only at
> build time and that optional deps remain optional. If there will be
> automation, how do we determine what optional deps to pull in?

I think that can still work. The main point of the "distro-y bits" is to 
make development easier, as well as provide actual documentation on how 
to make a binary package distro - not just a system built from source. 
There's a fair bit more to it than what LFS or the hints provide.

> What benefits can we expect for users who have already done the leg work
> to use other packaging methods?
> For instance, with what is put into the book, could a logical parser be
> made to genarate a spec file? How about dpkg?

If we did it correctly, I think this should be possible. It would 
definitely be nice to keep this as a goal. However we do it, it would be 
wise to make the spec generator modular enough to accept different 
output filters.

> While I admit that the .d/ directory reduces this concern immensely,
> what happens to configuration files that must be modified by additional
> installations? Do we keep diffs indefinitely, or do we create a comment
> marker for each package's additions, modify the package to support some
> sort of include directive? I can see scripting getting somewhat
> difficult here, not impossible, but difficult.

There's two features of most mature package managers that can help with 
this. First, config files can be identified in the spec so that when the 
version installed on the system is different than the one in the package 
being installed, a backup of one or the other is made, and the PM tells 
you what it did. So this helps preserve user modifications.

Second, for config files which we might reasonably expect to be modified 
by various installed system packages (e.g., /etc/passwd, /etc/group), 
those modifications can be done through pre- or post-install scripts, as 
well as pre- or post-uninstall scripts.

And yes, using .d directories where supported does help simplify things.

> If it is to be done, it should be designed with all goals in mind from
> the start. I have long suggested that LFS and BLFS move to installations
> from DESTDIR (or equivalent) as this does about 60% of building your src
> rpm without defining a particular package manager. The other 40% is just
> transposing what is in the book to spec, and could be automated, but
> even this has had lackluster support in the past despite the obvious
> educational benefits.

Absolutely. Looking forward to hearing more thoughts.


More information about the lfs-dev mailing list