Package: dh-elpa Version: 2.1.8 X-debbugs-cc: stefankan...@gmail.com Stefan K. is rewriting (info "(elisp) Packaging") and there might be some implications for how dh-elpa handles -pkg.el files.
Currently we encourage upstream to include them and generate them if they don't. It seems like we should be preferring to generate them: On Fri 07 Mar 2025 at 09:54pm GMT, Stefan Kangas wrote: >> (Of the 5870 packages on MELPA only four (all with the same maintainer) >> lack "<name>.el", forcing us to use their checked in "<name>-pkg.el" >> instead. I would like to drop support for *extracting* metadata from >> "<name>-pkg.el" in "package-build.el" (MELPA's "elpa-admin.el"), but >> until I can convince this one maintainer, I am unable to do so.) > > You should definitely drop support for that in MELPA. > AFAIK, GNU ELPA doesn't support it. > >> I also think it would be a good idea to explicitly state that a multi- >> file package named <name> should [I would prefer MUST] feature the >> library named <name>.el. IMO it is unfortunate that "elpa-admin.el" >> support using a another library via :main-file. There are only two >> packages taking advantage of that (tramp and matlab-mode), so for the >> sake of these two packages, "package-build.el" and every alternative >> package manager would have to support this too, for full compliance. > > I'd tend to agree. > -- Sean Whitton
