Hello Guix,
I’m referring here to the way we handle propagated-inputs in
package
definitions, when dependencies are already present in the latest
stable emacs we provide (28.2 as for today).
Think for example on all org-packages which depend on (and whose
package definition declare as a propagated-input) emacs-org.
This is
just an example, as many other similar examples may be found
(and more
to come on the upcoming 29.1).
From one side, it is up to the upstream package to declare in
the
package-requires fields all of its dependencies. Should not be
our
concern, as packagers, to take care of fixing / replacing that
in any
way.
But, from another perspective, most of these packages include
package-requires coherent to previous versions of emacs, which
is not
the case of guix.
So, do we need to pull most up to date dependencies, even if
already
present in current emacs, when upstream package requires them to
keep
backward compatibility ? Do we assume that guix emacs (28.2)
already
includes them, and remove the dependency from the inputs ? Is it
a
good strategy to install two different versions of a dependency
?
Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4,
which
is not specified in the package definition, meaning we always
pull the
latest available. Do we have to, provided that emacs releases
with org
?
Maybe there is already a clear rule about this topic, but to me
this
is not clear. We have package definitions with both criteria.
My two cents: let’s keep things as simple as possible. The lower
the
dependencies, the simpler the maintenance. I don’t see the point
on
pulling emacs-org@latest, provided that emacs already includes
the
minimun required org version. Same logic applies to all the
rest.
What do you think ?
Cayetano
