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
signature.asc
Description: PGP signature
