Hello,
As Emacs 30.1 is now heading for trixie, we face once more this issue
described in dh-elpa's documentation:
[Distinguish] packages that are maintained outside of the elpa-*
namespace in Debian, plus Emacs itself.
Also remove built-in packages, except those built-in packages
that are also packaged separately in Debian.
These are packaged separately for two reasons:
- it allows us to provide newer versions than those in Emacs core
- it permits use of addons with older versions of Emacs, for
which the dependency is not yet a built-in package.
A shortcoming is that for built-in packages, the Lisp in our elpa-*
packages always takes precedence, such that if we upload a new release
of Emacs with a version of one of these packages that's newer than the
one we have separately packaged, the older code will be loaded,
leading to hard-to-diagnose incompatibilities.
For the time being the upshot is that after uploading a new Emacs
release to sid, we also need to ensure everything listed here is
up-to-date with upstream in sid, too.
I am going to add something src:emacs's README.source to look at these
each release; this e-mail is to start us looking at them for this
release.
I think we should review what we actually want to keep and consider
removing them, based on how stable the package is now, how stable is
seems likely to remain.
let-alist
=========
Received substantive new functionality as recently as September 2024,
which addon packages may want to start depending on, so we should
probably keep it separately packaged.
Needs an update to a snapshot version, else installing elpa-let-alist constitutes a downgrade of functionality as compared with base Emacs.
Rémi, can you take a look?
transient
=========
We definitely want to keep this for newer versions of Magit.
I think it's already up-to-date.
seq
===
There was a decision from the two Stefans:
;; Note regarding the `seq' package on GNU ELPA:
;;
;; It was decided not to bother upgrading seq beyond 2.24 on GNU ELPA.
;; The main purpose of the GNU ELPA package was to encourage adoption
;; and accommodate changes more easily, but it's mature enough that
;; changes are fairly slow. Thus, we can now rely on "the usual"
;; solutions to deal with compatibility issues. (Bug#60990)
I think this creates an expectation that packages should rely on the
version of seq.el in the user's version of Emacs and raise their base
Emacs dependency if they can't do without more.
Therefore, we should remove this.
We'll need to clear all the rdeps first.
Xiyue and Aymeric, this might be a useful learning experience, would one
or both of you like to handle both clearing the rdeps and filing the RM
bug? You can just get started preparing the uploads, no need to wait
for each other. And then once it's done, an RM bug.
xref & project
==============
I originally packaged these because both were getting a revamp and I
thought they should be in Debian sooner.
They're now much more stable, and their development is entangled with
changes in core Emacs. I think it would be reasonable to expect users
to have to wait for a newer Emacs in order to get newer features in
these two libraries. GNU ELPA is already behind what's in Emacs 30.1 so
we'd be required to package a snapshot.
I'll file RC bugs to kick them out of testing and ask for objections to
filing RM bugs.
Org-mode
========
I assume we still want a separate package for this because it's such a
large thing of its own.
--
Sean Whitton
--=-=-Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAme+s1YZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQLx8D/0Q0e4Ovt1n4moPDqUt/HGs ghYDgkm6zw6sWZWQRphjHLcSOiRcIrqJTkOy2f+E2sarZGpApV2XAkHhY+x0cyNf V9XGK5ZJdDKH9JEZjKlc1PZteif0vkIh5Ztg0PlpvQr/hySWD1XUokqsyW67O3Us wUypX17gR8xv+doX0/Hu7kaFoQnnmO/10JSNV6dtVyq4zsXrBZGywlVdoq0a2Thy 7BwEaBJF27bzHa1UKr6Ofu4O7DOKFYMa0PxeGk/f376aePJCdz5uRXyzUjpaEyMY I+PsjpXQj+jQRQ/MsH1QCGnIoaucR5UTVIwZaU3x2BAWQipJ1ffufijYjYoE0Jst nrSOYGOKJesL5Avzw46U/RsFw7WtppyUxzLsyfSY046UJVQ7QGiHuZl+PKzEcuRP RYN4XZ4oHH4ldJvMikMirTdbUBMjiY8/dwBJ1GbOySCxmNMBEm7jaDhczh/neXrl h+CNjUnNlzLwTOO3K7TJL4PAovVSkswUXIquMaGvAdKR4I6a+QcuM8bJWAW3frT6 RuMMmr9b8S2Pd2eAYGFPOI0Ck5nwcYwicOWV0Hg+ur/vrq5YV0EUSN1w3tBIIsa6 vu+sAjjNsrka3QTSVhyBfcyU5sK9ljidu8q69wUg9EokZuqfEzSPnoa3r4p1ADqx jhRDCpn4GmMdyhh7yQ4/Lg=�Q3
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usen