Re: a short review of ricorambo/dh-elpa-extras
Hi,
Le samedi 28 octobre 2023 à 20:17, Nicholas D Steeves
<sten@debian.org> a écrit :
Is this because the metadata is missing in Emacs 29.1
(upstream bug, as I noted existed in my understanding of the
problem,
noted on #debian-emacs), or is it a bug in dh-elpa-extras?
This metadata is provided by the library "finder-inf"
(/usr/share/emacs/29.1/lisp/finder-inf.el), which sets the
variable package--builtins to a constant value.
The library "finder" (/usr/share/emacs/29.1/lisp/finder.el.gz)
also provides some utilities, in particular the function
finder-compile-keywords, that apparently parses all the source
elisp files part of the load-path, and produces the file
finder-inf.el. I am not entirely sure when this last file is
produced (at compile time ? by upstream themselves, just before
release ?).
The thing is, this library is apparently incapable of parsing the
source file of transient correctly (and possibly others). I think
this qualifies as an upstream bug, either in the finder library,
or in the header of transient.el.gz (maybe someone did not respect
some standard header format). Apparently, it looks for some header
"version", when in the case of transient, it should look for
"package-version". This could indeed be notified to upstream.
Oops, sorry, I missed this:
L9: http://paste.debian.net/1296572
Thanks for catching this issue!
Yes, the parser I implemented works at least for transient, so we
can consider this problem orthogonal with our purpose in the
meantime.
Moving on to your more important other points :
2. [ ] Can be run during the packaging of a $upstream_version-1
Debian
revision of src:emacs to solve the bootstrap problem.
I think the first question we want to ask ourselves is how we want
to inject this information in the control file : since we're
packaging a new version of emacs once every 18 months or so, we
could very well just do it manually and not bother with trying to
include it in the build process of src:emacs. How I saw things, I
imagined Someone(TM) would run the script, copy-paste the output
in the right place in the control file and then build and push
src:emacs. Of course, that Someone(TM) would have to remember to
do it. If Rob and Sean agree, I could be that someone and arrange
for this information to be included in the control file by pushing
it to salsa, every time they finish packaging a new version, and
before they push it.
On the other hand, if we absolutely want to include this info
automatically at build-time, we have to think about the
dependencies you mentioned. I needed aptitude to compute the list
of packages maintained by the team, and I am not aware of a tool
provided by an essential package that would allow us to do the
same. I chose aptitude because it allows to search in specific
fields of the control files, which apt-cache doesn't, if I'm not
mistaken. As for the rest, I just need to get the list of packages
provided by emacs from the finder-inf.el file, just after
compiling it. The whole schroot machinery can go away, since the
buildd machines run on unstable anyway (I needed them to make the
scripts work on my machine, that runs on stable). I'm also not
familiar at all with the rules file of src:emacs, so I wouldn't
know how to modify it.
I personnaly have a preference for the first solution, because I'm
lazy, but I'm curious what all of you think.
3. [ ] Please review your dependencies, because your work
depends on at
least one nifty tool from at least one Optional package.
I removed combine from the script calculate_intersection.sh, as it
was provided by moreutils. Thanks for catching this. As for the
other dependencies not provided by Essential packages, see my
previous point.
Thank you very much for your review.
Best,
Aymeric
Reply to: