>> 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.
> I think it's important to think about this in terms of forward
> compatibility. Is org-roam guaranteed to always work with "the current
> version of Emacs, whatever that may happen to be"? In that case, you
> could currently drop emacs-org. If it requires bleeding edge symbols
> on the other hand, or may freely decide that it will need them, adding
> emacs-org to the inputs is a good idea.
I don’t see your point. This is exactly the responsibility of the
package, declare its dependencies today, regardless of what the
dependencies will be in the future. This is what the ’package-requires’
field is for, including the version number of the dependencies.
If the dependencies of a given package are already there in emacs (say
org-9.2), why do we need to pull org-latest ? If in the future this
changes, an author decides he needs bleeding edge org features, and
changes the version number of org in the ’package-requires’ field, the
new package definition will propagage-require org-latest. All in all, we
may not predict future package needs, pulling dependencies just in case.
In any case, and whatever the decission, I think we should clearly state
the way to proceed somewhere, as currently we have a mix of both.
C.
