[lfs-dev] Once more: Package Management

Bryan Kadzban bryan at kadzban.is-a-geek.net
Sun May 20 11:18:22 PDT 2012


DJ Lucas wrote:
> Fortunately, that is not a deal breaker for me if the 
> readers get the same treatment (which seems to be the case), but this 
> does hard code optional dependencies for the pre-packaged installations. 
> This is both good and bad. From a development standpoint, it won't take 
> me a week to build a fairly standard system to test a simple package 
> upgrade, but that still means manual (or maybe only partially automated) 
> builds for omitting optional deps in the build process up to the point 
> that I need.

This exact reason, for the record, is why I really dislike binary
distros.  I *never* choose the same set of dependencies that are
optional in the source, as the distro does.  And because when they ran
./configure, they added a --with-foo flag, the package compiled with
-lfoo, meaning the binary version of the package now has a hardcoded
requirement for libfoo.so.N or whatever it is.

For example, python and bluez.  I don't want an entire bluetooth stack.
 But some distros' python packages require that stack in order to run.
For another example, gtk+ (both 2 and 3), or chrome, or firefox, and
CUPS: I don't want an entire printserver stack (since I only have a
single printer, and only use it from one machine).  Or xine-lib and ...
well, any half of its dependencies, depending on what you're going to
use it to play.  :-)

Now I should say that I don't think this necessarily applies to BLFS,
except inasmuch as testing with or without some of the optional
dependencies might require changes to the package in question.  (If the
CUPS-less version of FF needs some other configuration different from
the FF-with-CUPS binary, for instance.  I don't think that's the case
today at least.)  OTOH when building a system I can probably figure that
out, too.

> 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?

Perhaps it makes more sense to just keep ALFS the way it is, and not
build packages?  I *know* that I won't be building any package-ish thing
for my systems at all; I'm still using an oldish version of MSB's
package-user setup, so none of this applies.

In other words, I think it'd help to only use packages to simplify
(mostly BLFS) testing, but make them semi-public for people who really
want them.  Don't use them at all in the actual build instructions (what
would be the point?  :-) ), but generate the spec files, or whatever
equivalent, from the book XML.  (This last bit might be either hard or
impossible; I don't know.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20120520/ed9bf76d/attachment.sig>

More information about the lfs-dev mailing list