unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Andreas Enge <andreas@enge.fr>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: bug-guix@gnu.org
Subject: Re: Required packages
Date: Mon, 4 Feb 2013 23:28:11 +0100	[thread overview]
Message-ID: <201302042328.11563.andreas@enge.fr> (raw)
In-Reply-To: <87lib3pwa6.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]

Am Montag, 4. Februar 2013 schrieb 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?

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

[-- Attachment #2: Type: text/html, Size: 8562 bytes --]

  reply	other threads:[~2013-02-04 22:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-04 18:52 Required packages Andreas Enge
2013-02-04 22:08 ` Ludovic Courtès
2013-02-04 22:28   ` Andreas Enge [this message]
2013-02-05 16:50     ` Ludovic Courtès
2013-02-05 23:09       ` Andreas Enge
2013-02-06 22:09       ` Ludovic Courtès
2013-02-07 12:16         ` Andreas Enge
2013-02-07 12:27           ` Andreas Enge
2013-02-07 16:08             ` Ludovic Courtès
2013-02-07 16:06           ` Ludovic Courtès
2013-02-07 16:19             ` Andreas Enge
2013-02-07 21:39               ` Ludovic Courtès
2013-02-07 12:34         ` Andreas Enge
2013-02-07 16:09           ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201302042328.11563.andreas@enge.fr \
    --to=andreas@enge.fr \
    --cc=bug-guix@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).