Re: Required packages

[ludo@gnu.org (Ludovic Courtès)]

Andreas Enge <andreas@enge.fr> skribis:

> A question related to my previous posting, but also of independent 
> justification: Should we maybe implement somthing similar to the "depends" 
> field of Debian packages?

What’s this?

> For instance, programming with mpc also requires mpfr and gmp; in fact, the 
> first few lines of mpc.h read
>   #include "gmp.h"
>   #include "mpfr.h"
>
> So it would make sense to automatically pull in gmp and mpfr when a user 
> installs mpc. As dicussed with Ludovic, this could be handled by the 
> "propagated-inputs" field of the package definition.

s/could/should/  :-)

“Propagated inputs” was intended precisely for this use case.  I don’t
know why I didn’t use it but it’s a mistake since it requires packages
using MPC to know about MPC’s dependencies, and to hard-code them.

> But it also would make sense to not use such an automatism. For instance, 
> thanks to libtool, the mpc shared library is perfectly usable without 
> installing mpfr into the user profile, as libmpc.la contains a pointer to 
> the mpfr package:
>   dependency_libs=' /nix/store/l0999b93cw0by4hcv6z5ykzwz0gw358x-
> mpfr-3.1.1/lib/libmpfr.la /nix/store/ydxa85j3i21ac74dv0vbc6cxjjqpsfsv-
> gmp-5.1.0/lib/libgmp.la -lm'
> So a user who only wants to use a library and not develop with it may not 
> be interested in getting all the dependent headers in the user profile.

Yes, but mpfr.h and gmp.h still need to be in the user’s CPATH, which
contains ~/.guix-profile/include.  So putting them in the user’s profile
seems unavoidable.

I think you’re concerned about cluttering the user’s profile, right?

One thing that could be done to mitigate “cluttering” is to distinguish
between packages that were pulled as dependencies of what the user
installed, from packages the user explicitly installed (like apt does.)

WDYT?

> An obvious approach would be to split into library and devel packages, as 
> does debian. But I do not think we should go this road, it is quite 
> convenient to get all of mpc in only one package.

Yeah, I think it depends on the package.

The main criterion for determining whether to split in several outputs
would be the size of the closure of applications that use them.

Example: glibc is 37 MiB in total, plus 5 MiB for linux-libre-headers,
but lib/ is only 20 MiB.  So any application that uses glibc adds all
that to its closure.

GLib has 20 MiB of doc–good to avoid pulling that if all you want is to
run PulseAudio.  ;-)

Libtool’s “bin” output refers to the shell, which noticeably increases
the size of its closure.  Good to avoid that if all you want is
libltdl.so (like Guile does.)

But there are many more counterexamples, typically libraries of a few
hundred KiBs in total for which splitting is an inconvenience that
doesn’t provide any significant benefit.

Thoughts?

Ludo’.