Sean Whitton <spwhit...@spwhitton.name> writes: > 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
I have a quick and dirty script (attached) trying to find all packages that may have a corresponding builtin package (it may have missed a few though), and the result is the following: ,---- | elpa-xref | elpa-which-key | elpa-use-package | elpa-transient | elpa-seq | elpa-project | elpa-org | elpa-let-alist | elpa-faceup | elpa-eglot | elpa-editorconfig | elpa-compat | elpa-bind-key `---- Removing what Sean already mentioned, adding elpa-peg which is currently in the NEW queue, we have the following (sorted): ,---- | elpa-bind-key | elpa-compat | elpa-editorconfig | elpa-eglot | elpa-faceup | elpa-peg | elpa-use-package | elpa-which-key `---- According to etc/NEWS, editorconfig, which-key, peg, and compat are newly added in 30.1. Of those 8, editorconfig, which-key, eglot, bind-key, faceup, and use-package has no reverse dependency. elpa-peg was introduced for emacs-pg-el with the new upstream, and I guess elpa-compat will still be regularly updated. Maybe the 6 packages without rdepends can also be candidates to be kept from Trixie (or even RM)? -- Regards, Xiyue Deng
#!/bin/sh
for PKG in $(emacs -Q --batch --eval "(mapc #'(lambda (pkg) (progn (princ (car pkg)) (princ \"\n\"))) package--builtin-versions)"); do
ELPA_NAME="elpa-${PKG}"
FOUND=0
for RESULT_NAME in $(/usr/bin/apt-cache search --names-only "\b${ELPA_NAME}\b" | awk '{print $1}'); do
if [ "${ELPA_NAME}" = "${RESULT_NAME}" ]; then
echo "${RESULT_NAME}"
FOUND=1
break
fi
done
if [ "${FOUND}" -eq 1 ]; then
continue
fi
for RESULT_NAME in $(/usr/bin/apt-cache search --names-only "\b${PKG}\b" | grep -i emacs | awk '{print $1}'); do
if [ "${PKG}" = "${RESULT_NAME}" ]; then
echo "${RESULT_NAME}"
fi
done
done
signature.asc
Description: PGP signature
