Hi, Am Mittwoch, dem 01.02.2023 um 08:44 +0100 schrieb Cayetano Santos: > [D]o 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? The proper Guix way would actually be to unvendor those packages from Emacs and offer them separately. We could certainly do this for quite a number (e.g. org, cc-mode, ...), but it would be work that someone has to do and that person better not be lazy like me and take several months to add native-compilation ;)
> 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. Cheers
