emacs packaging: do we need to pull existing dependencies ?

[Cayetano Santos <cayetano.santos@l2it.in2p3.fr>]

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 deal with 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
  minimum required org version. Same logic applies to all the 
  rest.

What do you think ?

Cayetano