Re: Tiny Guix (and containers)

[Dave Love]

address@hidden (Ludovic Courtès) writes:

> Hi,
>
> Hartmut Goebel <address@hidden> skribis:

>> I'm in favor of (automatically?) splitting of "development" packages,
>> including the headers and the static libs (much like the "-devel" or
>> "-dev" packages in other distributions. One does not need them on a
>> production system and they are just wasting space. When Guix needs to
>> build a package, it automatically installs the ":devel" output of all
>> it's inputs.

I've been arguing for making sub-packages similar to other
distributions, but I'd expect to specify something like :devel as the
input to builds.  I'm not sure that it would even work generally to
infer it (e.g. when cross-compiling).

> We could do that (the Nixpkgs folks did exactly that a while back), but
> it won’t help that much.

It looks to me as if it would often help significantly, e.g. when a
pkg-config file, or something else sucks in a load of stuff that's
irrelevant for running the package.  (Separating :lib and needing that
for building means you need to know something about the packaging rather
than just using "devel", say.)

> What does help is running ‘guix size’, looking
> at specific packages that are problematic, then finding a solution for
> these packages—and often enough the solution is non-trivial.

I think it often will reflect the lack of separation of development
files, documentation, etc., and inclusion of static libraries, for
instance.  Boost is a case in point.  There's also the issue of multiple
copies/versions of packages in the closure, which seems problematic for
more than just size reasons.

> But yeah, I think we should track packages that are big or have a
> surprisingly build closure, and try to fix that incrementally!

Shouldn't that be done as a matter of course?  I don't remember if it's
part of Fedora or Debian packaging guidelines but packagers should check
dependencies for sanity when packaging, and there's some detection of
unnecessary linkage.  Guix' Qt dependencies are a striking example which
looks hard to resolve.  Generally I get surprised at what typically gets
built -- at great length! -- on updates or installation.