From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gammel Holte Subject: Re: Optional runtime dependencies in Guix Date: Mon, 12 Jan 2015 19:18:08 +0000 Message-ID: References: <87zjbh3arc.fsf@gnu.org> <87twzwuyn9.fsf@gnu.org> <87vbkcxhx3.fsf@gmail.com> <87fvbgrmn9.fsf@gnu.org> <20150112184614.GA4935@debian> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c13d0edf8168050c795dfe Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAkV9-0006fd-3Y for guix-devel@gnu.org; Mon, 12 Jan 2015 14:18:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAkV7-0006fR-V7 for guix-devel@gnu.org; Mon, 12 Jan 2015 14:18:11 -0500 In-Reply-To: <20150112184614.GA4935@debian> 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: Andreas Enge Cc: guix-devel@gnu.org --001a11c13d0edf8168050c795dfe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 12, 2015 at 6:47 PM, Andreas Enge wrote: > On Mon, Jan 12, 2015 at 05:26:02PM +0100, Ludovic Court=C3=A8s wrote: > > To begin with, we could have a =E2=80=9Cweechat=E2=80=9D package with a= =E2=80=9Creasonable=E2=80=9D > > option set: > > (define weechat > > (make-weechat "weechat")) > > > > And possibly another variant with, say, all the options enabled: > > (define weechat-full > > (make-weechat "weechat-full" #:python? #t #:lua? #t)) > > So far, our policy has rather been to enable all possible inputs. I think > this should be the default with the name "weechat" unaltered. If need be, > one could add another package with fewer inputs under the name > "weechat-small" or similar. > > What do others think? If there is consensus, we could formalise something > in the package naming section of the manual. > > Apart from that, I do not see why having several scripting languages > enabled > is a problem; in the end, it is quite likely that they are present anyway > due > to one package or another (it is rather difficult to avoid perl and pytho= n > these days!). So my real preference would be to not have such "...-small" > packages except for outrageously big default packages (texlive comes to > mind here...). > I disagree here. I have very functional Arch & Gentoo installs with no scripting language other than Perl, which is a dependency of many GNU tools= . In particular I'm doing just fine without Python. Installing everything by default is a bit suboptimal from a security point of view, especially if you're adding loads of interpreters. Also, if you're working on a constrained system, the fewer packages the better. I liked the solution of giving recommends or suggests for interpreters. > > A long term possibility would be to officially support something like > > Gentoo=E2=80=99s =E2=80=9CUSE=E2=80=9D flags. These would be declared = as part of the package, > > and the build process would take them into account somehow: > > To me, this sounds like overkill to solve a problem that I am not > convinced exists. > > Andreas > > > --001a11c13d0edf8168050c795dfe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 12, 2015 at 6:47 PM, Andreas Enge <andreas@enge.fr> wr= ote:
On Mon, Jan 12, 201= 5 at 05:26:02PM +0100, Ludovic Court=C3=A8s wrote:
> To begin with, we could have a =E2=80=9Cweechat=E2=80=9D package with = a =E2=80=9Creasonable=E2=80=9D
> option set:
>=C2=A0 =C2=A0(define weechat
>=C2=A0 =C2=A0 =C2=A0(make-weechat "weechat"))
>
> And possibly another variant with, say, all the options enabled:
>=C2=A0 =C2=A0(define weechat-full
>=C2=A0 =C2=A0 =C2=A0(make-weechat "weechat-full" #:python? #t= #:lua? #t))

So far, our policy has rather been to enable all possible inputs. I = think
this should be the default with the name "weechat" unaltered. If = need be,
one could add another package with fewer inputs under the name
"weechat-small" or similar.

What do others think? If there is consensus, we could formalise something in the package naming section of the manual.

Apart from that, I do not see why having several scripting languages enable= d
is a problem; in the end, it is quite likely that they are present anyway d= ue
to one package or another (it is rather difficult to avoid perl and python<= br> these days!). So my real preference would be to not have such "...-sma= ll"
packages except for outrageously big default packages (texlive comes to
mind here...).

I disagree here. I have = very functional Arch & Gentoo installs with no scripting language other= than Perl, which is a dependency of many GNU tools.

In p= articular I'm doing just fine without Python. Installing everything by = default is a bit suboptimal from a security point of view, especially if yo= u're adding loads of interpreters.

Also, if you'r= e working on a constrained system, the fewer packages the better.

I liked the solution of giving recommends or suggests for interpre= ters.


> A long term possibility would be to officially support something like<= br> > Gentoo=E2=80=99s =E2=80=9CUSE=E2=80=9D flags.=C2=A0 These would be dec= lared as part of the package,
> and the build process would take them into account somehow:

To me, this sounds like overkill to solve a problem that I am not convinced exists.

Andreas



--001a11c13d0edf8168050c795dfe--