Ricardo Wurmus <rek...@elephly.net> skribis: > Leo Famulari <l...@famulari.name> 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’.
