From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Enge Subject: Re: Required packages Date: Mon, 4 Feb 2013 23:28:11 +0100 Message-ID: <201302042328.11563.andreas@enge.fr> References: <201302041952.22425.andreas@enge.fr> <87lib3pwa6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary-01=_7XDERRgfpWTwt+n" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:52993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2UWW-0005UB-Af for bug-guix@gnu.org; Mon, 04 Feb 2013 17:28:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2UWT-0005q2-7z for bug-guix@gnu.org; Mon, 04 Feb 2013 17:28:24 -0500 In-Reply-To: <87lib3pwa6.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Ludovic =?utf-8?q?Court=C3=A8s?= Cc: bug-guix@gnu.org --Boundary-01=_7XDERRgfpWTwt+n Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Montag, 4. Februar 2013 schrieb Ludovic Court=C3=A8s: > Andreas Enge 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=E2=80=99s this? When A "depends on" B in debian jargon, then installing A automatically=20 also installs B. In our case, a user issuing "guix-package -i mpc" would=20 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=3D' /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. >=20 > Yes, but mpfr.h and gmp.h still need to be in the user=E2=80=99s CPATH, w= hich > contains ~/.guix-profile/include. So putting them in the user=E2=80=99s = profile > seems unavoidable. Probably so; come to think of it, the cases where one wants to link against= =20 a dynamic library, but not write source code using the headers, should be=20 really rare (linking a compiled program against a newer version of the=20 library would be a possible case, which is somewhat contrary to the guix=20 philosophy). > I think you=E2=80=99re concerned about cluttering the user=E2=80=99s prof= ile, right? Not really. I just wonder what we should do, and what a user would expect.= =20 =46or instance, in debian, gcc depends on binutils and the glibc. So when y= ou=20 install gcc, you also get the other two packages. Is this what we want or=20 not? > One thing that could be done to mitigate =E2=80=9Ccluttering=E2=80=9D 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=20 pulled in automatically. Then should they be uninstalled with the package=20 that pulled them in? That is a bit complicated: If A and B need C and the=20 user installs A and B (and thus also obtains C), C can only be uninstalled= =20 when A _and_ B are gone. Andreas --Boundary-01=_7XDERRgfpWTwt+n Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Am Montag, = 4. Februar 2013 schrieb Ludovic Court=C3=A8s:

> Andrea= s Enge <andreas@enge.fr> skribis:

> > A= question related to my previous posting, but also of independent

> > j= ustification: Should we maybe implement somthing similar to the

> > &= quot;depends" field of Debian packages?

> What= =E2=80=99s this?

&nb= sp;

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

&nb= sp;

> > B= ut it also would make sense to not use such an automatism. For

> > i= nstance, thanks to libtool, the mpc shared library is perfectly

> > u= sable without installing mpfr into the user profile, as libmpc.la

> > c= ontains a pointer to

> > t= he mpfr package:

> > = dependency_libs=3D' /nix/store/l0999b93cw0by4hcv6z5ykzwz0gw358x-

> > m= pfr-3.1.1/lib/libmpfr.la /nix/store/ydxa85j3i21ac74dv0vbc6cxjjqpsfsv-

> > g= mp-5.1.0/lib/libgmp.la -lm'

> > S= o a user who only wants to use a library and not develop with it may

> > n= ot be interested in getting all the dependent headers in the user

> > p= rofile.

>

> Yes, b= ut mpfr.h and gmp.h still need to be in the user=E2=80=99s CPATH, which

> contai= ns ~/.guix-profile/include. So putting them in the user=E2=80=99s profile<= /p>

> seems = unavoidable.

&nb= sp;

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 b= e a possible case, which is somewhat contrary to the guix philosophy).

&nb= sp;

> I thin= k you=E2=80=99re concerned about cluttering the user=E2=80=99s profile, rig= ht?

&nb= sp;

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

&nb= sp;

> One th= ing that could be done to mitigate =E2=80=9Ccluttering=E2=80=9D is to disti= nguish

> betwee= n packages that were pulled as dependencies of what the user

> instal= led, from packages the user explicitly installed (like apt does.)

&nb= sp;

This would = be the next question, only relevant if packages are indeed pulled in automa= tically. 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 an= d B (and thus also obtains C), C can only be uninstalled when A _and_ B are= gone.

&nb= sp;

Andreas

&nb= sp;

--Boundary-01=_7XDERRgfpWTwt+n--