Re: Tiny Guix (and containers)

[Ludovic Courtès]

Heya,

Dave Love <address@hidden> skribis:

> 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).

OK.

>> 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.)

Right, good point.

The nice thing with “lib” and “doc” is that it has a direct mapping to
the GNU directory classification (libdir, docdir, etc.)

Now, we could depart from it and go with “devel”, for the reasons you
give.  Let’s experiment and see how it goes!

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

Boost is also a special case, being a mostly-header library.  :-)  But
yeah, I get your point.

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

No argument here!

The guidelines at
<https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html>
also mention the closure size.

We can clearly do better though, and what you’ve been doing with
Open MPI et al. is a step in the right direction IMO.

I would very much welcome experiments introducing “devel” outputs.
Perhaps as a first step we could make it opt-in.  We would add support
for that in gnu-build-system.scm, and then modify key packages to use
“devel” instead of “lib”, for example.  Incremental changes like this
can be tractable.

Thoughts?

Ludo’.