From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: Proposal: Prefix language-name for language library packages Date: Mon, 02 May 2016 11:33:23 +0200 Message-ID: <87zis8iz30.fsf@libertad.pw> References: <20160429233632.GA13525@jasmine> <87oa8rwqhc.fsf@elephly.net> <877ffcgap8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axAFe-0005y7-R6 for guix-devel@gnu.org; Mon, 02 May 2016 05:34:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axAFS-00040o-JJ for guix-devel@gnu.org; Mon, 02 May 2016 05:34:45 -0400 Received: from hello.itaskmanager.ovh ([2001:41d0:2:1415::1]:57954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axAFS-0003vI-D3 for guix-devel@gnu.org; Mon, 02 May 2016 05:34:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by hello.itaskmanager.ovh (Postfix) with ESMTP id 83F2D6261B for ; Mon, 2 May 2016 11:36:06 +0200 (CEST) Received: from hello.itaskmanager.ovh ([127.0.0.1]) by localhost (itaskmanager.ovh [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yae2QtzPDAyn for ; Mon, 2 May 2016 11:36:05 +0200 (CEST) Received: from durin (xd9bb8192.dyn.telefonica.de [217.187.129.146]) (Authenticated sender: ng0@libertad.pw) by hello.itaskmanager.ovh (Postfix) with ESMTPSA id 296DE6261B for ; Mon, 2 May 2016 11:35:41 +0200 (CEST) In-Reply-To: <877ffcgap8.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 02 May 2016 09:50:43 +0200") 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" To: guix-devel@gnu.org ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Ricardo Wurmus skribis: > >> Leo Famulari writes: >> >>> On Fri, Apr 29, 2016 at 06:31:24PM +0000, al=C3=ADrio eyng wrote: >>>> Ludovic Court=C3=A8s: >>>> >what about multiple-language packages? I=E2=80=99m thinking of >>>> >=E2=80=98c+guile-guile=E2=80=99 and =E2=80=98c+siod+python-gimp=E2=80= =99. >>>> the ideal categorization would be one output for each interface. >>>> so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod", >>>> "gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run >>>> "emacs -batch -eval"). >>>> e.g. guile:c and emacs:tui are pretty useless for me, so i could not >>>> install them. >>>> it's worth to focus on packages already split: "emacs" (gui+tui+elisp) >>>> and "emacs:no-gui" (tui+elisp), linux-libre, ... >>> >>> I don't think we should split packages up unless there is a pressing >>> reason to do it. For example, some our packages have a rarely-used >>> component that uses a lot of disk space or has a very large dependency. >>> It makes sense to put those in different outputs. >>> >>> But if we go too far, nobody will be able to tell which package to >>> install to accomplish their task. >> >> I agree. I=E2=80=99d like to only split up packages when the effort is >> justified. > > Agreed. > > FWIW, until recently Nixpkgs didn=E2=80=99t use multiple outputs much (in= fo > "(guix) Packages with Multiple Outputs"). Lately they merged a change > to use them very aggressively. So for instance, GNU=C2=A0libidn, which t= akes > 800=C2=A0KiB in total, has no less than 5 outputs: > > https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries= /libidn/default.nix > > I think this is going a bit too far. :-) > > I think the approach should be to profile packages with =E2=80=98guix siz= e=E2=80=99 and > to act mostly on a case-by-case basis. > > Ludo=E2=80=99. > To add my thoughts on this: I think multiple language packages could be nice, but they could also make getting into packaging incredible harder. Currently it is very accessible and modular. It would also introduce labeling problems and discussions, does someone see it's mainly this and that language? Do we then decide on the order of $lang in $lang+$lang+$lang-$package or do we waste our times with individual package discussions and preferences and also when to split up or not? If we decide on something, it should be covering all possibilities and minimize discussions which might arise from it. If we decide on one thing now we don't have to stick to it for all eternity, it can change later if we see it doesn't work out anymore. Gentoo used to have herds, project groups for certain big or themed projects. In the last council meeting they decided that herds are no longer needed and wanted by the community, so they are splitting them up. --=20 =E2=99=A5=E2=92=B6 ng0