Hi Nicolas,
Nicolas Graves <ngra...@ngraves.fr> writes:
On 2025-04-05 09:38, Ian Eure wrote:
Hi Ian, thanks for this discussion.
This is my (d) (better policy proposition):
a) Leave it as is. Don’t love it, but if there’s concensus
that
this is the right way, then okay.
I'd argue sometimes it's indeed the better solution, especially
when
the core of the package needs the binary to work properly, not
when it's
an additional option or feature. I'll refer to that as
"essential
binary" in the rest.
I appreciate this line of thinking, but suspect that whether a
binary is essential or not depends on the user’s usecase, which is
unknowable at package build time. For a user using EMMS to play
MP3s, flac isn’t essential, and mpg321 is; for someone using it to
play FLACs, the inverse is true.
(This is the case where not having the binary is absurd because
it
renders the emacs package unusable).
I think it’s important to distinguish between "unusable" and "not
usable unless the user takes some action."
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?
I agree this is nice, but maybe it's enough to do that in Emacs
packages
themselves (ensuring they suggest the missing binary when it's
not
found) rather than in Guix Home itself.
I also like this idea; do you have an idea what an implementation
for that would look like? Presumably upstream package authors
wouldn’t want Guix-specific stuff in packages that need to work on
any OS/distro.
-- Ian
