bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Required packages


From: Andreas Enge
Subject: Re: Required packages
Date: Mon, 4 Feb 2013 23:28:11 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

Am Montag, 4. Februar 2013 schrieb Ludovic Courtès:

> Andreas Enge <address@hidden> 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?

 

When A "depends on" B in debian jargon, then installing A automatically also installs B. In our case, a user issuing "guix-package -i mpc" would end up with gmp, mpfr and mpc in the profile.

 

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

 

Probably so; come to think of it, the cases where one wants to link against a dynamic library, but not write source code using the headers, should be really rare (linking a compiled program against a newer version of the library would be a possible case, which is somewhat contrary to the guix philosophy).

 

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

 

Not really. I just wonder what we should do, and what a user would expect. For instance, in debian, gcc depends on binutils and the glibc. So when you install gcc, you also get the other two packages. Is this what we want or not?

 

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

 

This would be the next question, only relevant if packages are indeed pulled in automatically. Then should they be uninstalled with the package that pulled them in? That is a bit complicated: If A and B need C and the user installs A and B (and thus also obtains C), C can only be uninstalled when A _and_ B are gone.

 

Andreas

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]