It looks like the upstream discussion[1] may still go on for a while:
the direction has consensus, while the details of the functions are
still under discussion.
In the meantime, I wonder whether we can move forward on the Debian side
and have this in Trixie (with an unblock request), which will help users
who upgrade from Bookworm avoid surprises when older versions of addons
are installed. My branch[2] is updated to the latest version of
upstream bug. Patches are also attached.
I think there are values for including other packages which helps with security updates. For example, we have Org 7.9.11 shipped with Emacs
30.1; later if a security bug is found in 7.9.11, and Emacs 30.2 ships a newer version of Org to fix that, this gets automatically taken care of
by this.
FYI, upstream merged my proposed patch in bug#78844[1]. I'd still
advocate for its inclusion in Trixie to make the upgrade experience
smoother for dropped packages (e.g. eglot, project, etc.) Though I do acknowledge that we are already in the late stage of the Trixie release cycle, and it's probably safe to maintain the status quo. If the latter
is chosen, I wonder whether this may still be a good candidate for a
future stable update, or only be suitable for a backport?
Xiyue Deng <[email protected]> writes:
[...]
But I think we can do the following:
- Let's start preparing the versioned Provides generation in
experimental. Assume I'l backport your patch in #78844 to Emacs 30.
Can you prepare a patch implementing the Provides generation?
The patches I attached to [3] implemented this (as well as in my
branch[4] which could be newer). It didn't backport bug#78844 in the
Emacs source, but host identify copies of the new functions in the
provides/breaks/replaces generation code (which are guarded by fboundp
so that the Emacs implementations will be used when available in Emacs
31). I think this has the advantage that we won't hit any conflicts
when upgrading.
I just realized that you have already done the backporting of #78844.
The patches still work (as it's guarded by fboundp), but do you want me
to remove the vendored functions?
Sean Whitton <[email protected]> writes:
Hello,
On Tue 15 Jul 2025 at 10:45am -07, Xiyue Deng wrote:
Acknowledged. I thought there was a bug report from Stefano about the
upgrading issue regarding Emacs backports, which turns out to be just an >>> email to debian-backports[1]. That said, Cyril seemed to support this
idea for a better upgrade experience, though not officially as a RT
member. As the issue is real, maybe we can file this as an important
bug? (It would sound a bit like tricking the system though but not
really :P)
Still, I'm also OK with postponing this to Forky to avoid causing
additional issues.
No -- my suggestion is to add manually generated
Provides/Conflicts/etc. to trixie to fix this problem.
Just to confirm: is the substvars based solution OK for Trixie (as done
in my updated patchs in my other email), or were you expecting the provides/replaces info directly put in d/control (like my earlier
approach based on d/control.in but only keep the generated d/control)?
Sean Whitton <[email protected]> writes:
Hello Xiyue,
This is great work. Thank you for the respin. I'd just like to ask a
few questions about it.
- What is the emacs-provided-package-versions variable for? I don't
think it gets set anywhere?
It's used later in the `emacs-provided-package-versions` function, which
will populate it with a mapping of package name to version. This will
then be used later to actually generate the substvars values.
It also gets regenerated with `debian/rules debian-sync': notice that
the build rule is marked `.PHONY'. I think this should be run on each
update according to d/README.source. Maybe this could be added to dh_auto_clean in case someone (like me) forgets to run it by hand?
This makes the development easier so that I don't have to sbuild it
every time to test (which takes ~20min for me). Also, running the
script needs a working emacs executable (I'm using `/usr/bin/emacs')
which is not available yet during build (or it can some built emacs executable in some build-path, but I think it's a bit too fragile).
And I realize that because I removed the vendored lisp functions to get
the built-in package information, the script currently cannot work until Emacs with the backported package.el is released. So probably we should upload -6 first (in experimental)?
Hi Sean,
Sean Whitton <[email protected]> writes:
Hello Xiyue,
Thanks. I think you sent the wrong patches
Oops, sorry.
but I had a look at your
branch on salsa. This still isn't quite what I mean. I think that
- you should be using the Emacs built binary (as you are now doing)
- we should not commit the file emacs-common-substvars to git.
Instead it should be generated during the build.
So the main thing missing is that the generating of the file should be
incorporated into the build. Probably it should go into the existing
override_dh_auto_install.
I understand that this file is mostly useful during package building.
Still, I'd like to give another try to propose to have debian/emacs-common-substvars committed in git: this will help with
debugging in the following scenarios:
* When we want to understand why some packages are (or not) being
replaces by Emacs, and
* When we want to see what packages are updated between Emacs releases
(which is also why I put a package+version per line in the comments).
Without this file, we need to get this information from `apt show' or
from https://packages.debian.org/ which would be very cumbersome and
hard to get it right.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 42:53:46 |
| Calls: | 12,110 |
| Calls today: | 1 |
| Files: | 15,008 |
| Messages: | 6,518,438 |