[lfs-dev] Once more: Package Management
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
> 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...
Size: 261 bytes
Desc: OpenPGP digital signature
More information about the lfs-dev