guix-devel
[Top][All Lists]
Advanced

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

Re: Proposal: Prefix language-name for language library packages


From: ng0
Subject: Re: Proposal: Prefix language-name for language library packages
Date: Mon, 02 May 2016 11:33:23 +0200

address@hidden (Ludovic Courtès) writes:

> Ricardo Wurmus <address@hidden> skribis:
>
>> Leo Famulari <address@hidden> writes:
>>
>>> On Fri, Apr 29, 2016 at 06:31:24PM +0000, alírio eyng wrote:
>>>> Ludovic Courtès:
>>>> >what about multiple-language packages?  I’m thinking of
>>>> >‘c+guile-guile’ and ‘c+siod+python-gimp’.
>>>> 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’d like to only split up packages when the effort is
>> justified.
>
> Agreed.
>
> FWIW, until recently Nixpkgs didn’t use multiple outputs much (info
> "(guix) Packages with Multiple Outputs").  Lately they merged a change
> to use them very aggressively.  So for instance, GNU libidn, which takes
> 800 KiB 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 ‘guix size’ and
> to act mostly on a case-by-case basis.
>
> Ludo’.
>

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.

-- 
♥Ⓐ ng0



reply via email to

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