From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gammel Holte Subject: Re: Optional runtime dependencies in Guix Date: Sun, 11 Jan 2015 15:38:38 +0000 Message-ID: References: <87zjbh3arc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bf0cc00fe321a050c622ec2 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAKbB-0005ub-89 for guix-devel@gnu.org; Sun, 11 Jan 2015 10:38:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAKb9-0004JF-GO for guix-devel@gnu.org; Sun, 11 Jan 2015 10:38:41 -0500 In-Reply-To: <87zjbh3arc.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel@gnu.org --047d7bf0cc00fe321a050c622ec2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Apologies for the really late reply. Sadly I was ill for the best part of December. So I wouldn=E2=80=99t claim this is a solved problem, because it really get= s > fixed when we discover a problematic case, and we certainly overlook > some of them. Yet, that=E2=80=99s something I pay attention to, and I th= ink we > must clearly look to address more of such issues. > > WDYT? > I am super excited about Guix and the system seems to be progressing very quickly. Loads of commits everyday. However, the more I dig into Guix, the more i see this as an urgent issue. For example, consider samtools, a package I use daily and that was recently committed to Guix: http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bioinformatics.= scm#n139 It forces me to install python. In contrast, consider Arch AUR's package: https://aur.archlinux.org/packages/samtools/ Python is listed an optional dependency. In my opinion, it is highly undesirable that Guix doesn't have a mechanism to decouple packages from optional dependencies. This scenario seems to be arising mostly in case of interpreters that may be called by the program to execute some optional stuff. An extreme example of this is weechat: http://lists.gnu.org/archive/html/guix-devel/2014-09/msg00229.html Compare with: https://www.archlinux.org/packages/extra/i686/weechat/ Guix version forces the user to install all interpreters for running user-defined scripts to extend Weechat. These are quite many: lua, perl, python, ruby, tcl (and guile). I understand Guix/Nix philosophy and I adhere to it. But at some point we need to draw the line between a dependency and dynamic linking. Otherwise, installing a package may lead to many undesired dependencies getting installed. This has many implications, including security ones. Best wishes, A. On Sun, Nov 23, 2014 at 8:47 PM, Ludovic Court=C3=A8s wrote: > Hello, > > Gammel Holte skribis: > > > Nix doesn't have a good decoupling between packages and their optional > > runtime dependencies. You can disable them, but this would lead to a > > different package hash, and thus a different build (negating the use of > > prebuilt binaries). > > > > Therefore, the culture seems to have all default package builds with al= l > > optional runtime dependencies on. This leads to situations such as > > installing mutt, and getting python as a dependency (via mutt -> gpgme = -> > > glib -> python), which is quite ugly. > > That=E2=80=99s indeed undesirable. > > As I just wrote to Taylan Ulrich, this is currently handled on a > case-by-case basis using multiple outputs (which I think Nixpkgs doesn=E2= =80=99t > use a lot yet.) > > For instance, GLib has a separate =E2=80=9Cbin=E2=80=9D output for this v= ery reason (see > .) Git, as I wrote, has separate outputs for > git-svn and Tcl stuff. Same for WordNet. There are also separate > outputs for debugging symbols. > > So I wouldn=E2=80=99t claim this is a solved problem, because it really g= ets > fixed when we discover a problematic case, and we certainly overlook > some of them. Yet, that=E2=80=99s something I pay attention to, and I th= ink we > must clearly look to address more of such issues. > > WDYT? > > Thanks, > Ludo=E2=80=99. > --047d7bf0cc00fe321a050c622ec2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologie= s for the really late reply. Sadly I was ill for the best part of December.=

So I wouldn=E2=80= =99t claim this is a solved problem, because it really gets
fixed when we discover a problematic case, and we certainly overlook
some of them.=C2=A0 Yet, that=E2=80=99s something I pay attention to, and I= think we
must clearly look to address more of such issues.

WDYT?

I am super excited about Guix and the syste= m seems to be progressing very quickly. Loads of commits everyday. However,= the more I dig into Guix, the more i see this as an urgent issue.

For example, consider samtools, a package I use daily and that w= as recently committed to Guix:

http://git.savan= nah.gnu.org/cgit/guix.git/tree/gnu/packages/bioinformatics.scm#n139
=
It forces me to install python. In contrast, consider Arch AUR= 9;s package:

https://aur.archlinux.org/packages/samtools/

Python is l= isted an optional dependency. In my opinion, it is highly undesirable that = Guix doesn't have a mechanism to decouple packages from optional depend= encies. This scenario seems to be arising mostly in case of interpreters th= at may be called by the program to execute some optional stuff.

An extreme example of this is weechat:

http://lists.gnu.org/ar= chive/html/guix-devel/2014-09/msg00229.html

Compare with:<= br>
h= ttps://www.archlinux.org/packages/extra/i686/weechat/

Guix= version forces the user to install all interpreters for running user-defin= ed scripts to extend Weechat. These are quite many: lua, perl, python, ruby= , tcl (and guile).

I understand Guix/Nix philosophy and I adhe= re to it. But at some point we need to draw the line between a dependency a= nd dynamic linking. Otherwise, installing a package may lead to many undesi= red dependencies getting installed. This has many implications, including s= ecurity ones.

Best wishes,
A.
<= div>

On Sun, Nov 23, 2014 at 8:47 PM, Ludovic Court=C3=A8s <ludo@gn= u.org> wrote:
Hello,

Gammel Holte <gammel.holte@gma= il.com> skribis:

> Nix doesn't have a good decoupling between packages and their opti= onal
> runtime dependencies. You can disable them, but this would lead to a > different package hash, and thus a different build (negating the use o= f
> prebuilt binaries).
>
> Therefore, the culture seems to have all default package builds with a= ll
> optional runtime dependencies on. This leads to situations such as
> installing mutt, and getting python as a dependency (via mutt -> gp= gme ->
> glib -> python), which is quite ugly.

That=E2=80=99s indeed undesirable.

As I just wrote to Taylan Ulrich, this is currently handled on a
case-by-case basis using multiple outputs (which I think Nixpkgs doesn=E2= =80=99t
use a lot yet.)

For instance, GLib has a separate =E2=80=9Cbin=E2=80=9D output for this ver= y reason (see
<http://bugs.gnu= .org/17853>.)=C2=A0 Git, as I wrote, has separate outputs for
git-svn and Tcl stuff.=C2=A0 Same for WordNet.=C2=A0 There are also separat= e
outputs for debugging symbols.

So I wouldn=E2=80=99t claim this is a solved problem, because it really get= s
fixed when we discover a problematic case, and we certainly overlook
some of them.=C2=A0 Yet, that=E2=80=99s something I pay attention to, and I= think we
must clearly look to address more of such issues.

WDYT?

Thanks,
Ludo=E2=80=99.

--047d7bf0cc00fe321a050c622ec2--