l...@gnu.org (Ludovic Courtès) writes: > 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’. >
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
