Hello,
Le mercredi 23 novembre 2022 à 14:00, Sean Whitton
<spwhit...@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 might
need 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
dependency
available.
I don't think we should be adding Provides/Breaks anywhere
without
considering 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
