bug-guix
[Top][All Lists]
Advanced

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

Re: Required packages


From: Ludovic Courtès
Subject: Re: Required packages
Date: Tue, 05 Feb 2013 17:50:12 +0100
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)

Andreas Enge <address@hidden> skribis:

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

OK.  That’s “user-environment-propagated-inputs”.  We could achieve that
by just changing guix-profile to install propagated inputs.  That’s
probably the right thing to do anyway.

[...]

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

Yes.

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

In the general case, I think so, yes.

Installing MPC should definitely install MPFR and GMP.

Similarly for Guile 2.0, whose public headers refer to libgc’s.

For GCC, the situation is more complicated, because GCC has a loose tie
to Binutils and libc.  For instance, it happily takes whichever ‘ld’
program is in $PATH.  It’s more closely tied to libc, though, because we
explicitly patch its spec strings to refer to it; so at least libc
should be a propagated input of GCC.

WDYT?

Thanks,
Ludo’.



reply via email to

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