Hello,Le mercredi 23 novembre 2022 à 14:00, Sean Whitton <spwhitton@spwhitton.name> a écrit :
elpa-transient isn't a transitional package -- we'll keep it in Debian even after Emacs 28 is the only Emacs we have. This is because we mightneed a newer version of transient available for another package.So far our strategy has been to handle this in the code in dh_elpa that generates dependencies, and also not worry about it too much, unless we get a combination that results in something not having its dependencyavailable.I don't think we should be adding Provides/Breaks anywhere withoutconsidering corresponding changes in dh_elpa.
The change we have used previously was to add the package in question (then org, in the present case transient) to the list of separately packaged libraries in the dhelpa-filter-deps-for-debian.
This would create a hard dependency on elpa-transient, regardless of the available version of the same library in the bundled version of emacs. This would solve the problem of elpa-ement and elpa-snakemake.
However, this packaged version of elpa-transient would also shadow the transient shipped with emacs, regardless of their respective versions.
The use of the Provides: mechanism proposed by Mr. Beckmann on the emacs-common package (which is independent from the changes made in dh-elpa that would need to be done anyway) would prevent that, and also allow apt to save installing a package (elpa-transient) only when the emacs-common version is high enough.
This would only require computing, for each elisp libraries shipped with emacs that we also package separately, the version provided by the current version of emacs. A corresponding versioned Provides: field would be then added to emacs-common.
I.E. a loop around something like this : (package-desc-version (cadr (assq 'transient package-alist)))This is in fact a simpler and more elegant solution than the one I proposed in [🔎] 87h6zai8qp.fsf@EBx360.
Best, Aymeric