This is a follow-up of bug#1103033[1], which added built-in package
information now being part of the Breaks/Replaces/Provides info on
package `emacs-common'.  I'm now suggesting generate and stores the
built-in package version information in the Debian packaging source as
metadata to help debugging by enabling the following usage:

* Makes it easy to check which built-in packages replace externally
  packaged packages, which may help on security updates.

* Help track built-in package version information and provide a
  reasonable diff on package upgrades.

Note that this info is available in the package info of `emacs-common'
but it has everything in one line which makes it hard to track.

(Ideally this could be part of bug#1103033 but it requires an Emacs with
the backported package.el functions which is not available until
1:30.1+1-7.)

[1] https://bugs.debian.org/1103033

Hello Xiyue,

Thanks.  A few comments:

- how about using a sexp rather than JSON, since we are Lispers around
  here? :)
- how about installing the file somewhere?  might be useful for other
  things to reference the information
- let's use the debian/emacs-nox/emacs again, so that there is no chance
  the information goes out-of-sync.

Hi Sean,

Thanks for your comments!

Sean Whitton <spwhitton@spwhitton.name> writes:

My intention is for this to be simple and human readable, so a
one-line-per-entry kind of format that is more universally accessible
would be ideal, which is why I chose JSON.  Sexp is of course native to
Lisp environments, but as we now have a fast JSON parser built-in to
Emacs it's not that bad if we want to use this info in Elisp :)

This information is provided by apt-cache/dpkg already for external
tools, so I don't think providing another separate source would help
more.  As mentioned in the previous mail, this is currently intended to
be useful for maintainers for keep tracking, so storing in the source
packaging and accessible through Salsa should be good enough for now.

See above.

Now admittedly, this is more like a design-for-future thing, so it's
possible that this turns out to be not really useful.  I'm OK if we want
to keep things simple for now and revisit this when there is an actual
need to add this info.

Hello,

Okay.

Okay.  Let's leave this bug open, then.