Hi Ian, On Sat, 05 Apr 2025 at 09:38, Ian Eure <i...@retrospec.tv> wrote:
> a) Leave it as is. Don’t love it, but if there’s concensus that > this is the right way, then okay. Somehow, the consensus has been to have “maximally” featured packages – roughly speaking – and use -minimal when not. For instance, Alpine does the contrary: emacs is “minimal” and then emacs-gtk3, emacs-nox, etc. Although I personally prefer Alpine approach, until now, this approach does not seem floating in Guix atmosphere. :-) Somehow, the closure is much too large, IMHO. > b) Make packages that align better with specific usecases, > ex. emacs-emacsql-sqlite, -mysql, etc. This feels fraught to me, > and I don’t think it works if you get emacs-emacsql-sqlite as an > input to some other emacs-* package, but want emacs-emacsql-mysql > as a user. Perhaps metapackages which only exist to combine > dependencies would make this a workable approach. I’ve never read the Alpine policy but I guess they have one. :-) > d) Have some better policies around when to use inputs and when > not to. This might be the most pragmatic approach, though it > means inconsistency from package to package. To me the only question is about the default. Is emacs-emms “maximally” featured thus compiled with most – if not all – the backends? Or is emacs-emms “minimally” featured thus not really working out-of-the-box? > e) Build a suggested package mechanism into Guix. This has been > floated a couple times before. If it defaults to not installing > suggested packages, but telling the user about them, this would > be like option C, but making it easier to find which packages you > might need; if it installs them by default, it would work like > the current setup, but give users some kind of out to avoid the > extra bandwidth/disk usage. I don’t know how this would work for > declarative package setups -- how would I express to Guix Home > that it should install emacs-emms with flac (for metaflac), but > without mpg321, vorbis-tools, and mp3info? Somehow, it would rely on parameterized packages as mentioned elsewhere in the thread, no? Well, that’s interesting but how we can learn with Gentoo’s experiment, this approach leads to some combinatorial issues: It would be hard to provide substitutes or to have some guarantee that some combinations of parameters indeed build together or work together. Hum, good question! :-) All in all, you raise a good topic… and it will be difficult to change the current status quo, IMHO. Cheers, simon
