Bug#867042: lintian: new tag: emacsen-common-without-dh-elpa
Control: tags -1 moreinfo
On Mon, 3 Jul 2017 17:48:44 +0100 Sean Whitton
<spwhitton@spwhitton.name> wrote:
> Package: lintian
> Version: 2.5.51
> Severity: wishlist
> Tags: patch
>
> Hello Lintian maintainers,
>
> Please consider merging branch `elpa` of my repository.[1] It passes
> the Lintian test suite on my machine.
>
> This adds a new tag, emacsen-common-without-dh-elpa. It is a buster
> release goal of the pkg-emacsen team to eliminate Emacs addons not using
> dh-elpa, except those intended for use with XEmacs (a minority), and
> this tag will assist greatly in finding those packages, and preventing
> new ones from being uploaded.
>
> To help justify the 'W' severity, I would like to note that packages for
> which Lintian would emit this tag are basically the reason why emacs25
> is not the default Emacs in stretch. Further, there was at least one
> other RC bug during the freeze due to buggy emacsen-common maintscripts.
> dh-elpa lets us have just one source package with a copy of those
> maintscripts (dh-elpa itself), using declarative packaging in the source
> package for each addon (debian/*.elpa).
>
> Thanks.
>
> [1] https://git.spwhitton.name/lintian
>
> [...]
Hi Sean,
Thanks for the patch.
I have one clarification before I review it further. During the stretch
release, the release team noticed that dh-elpa added "Built-Using"
fields to a lot of packages. Notably, it has the side effect of keeping
old versions of the dh-elpa source around.
Before we start to rely on it in lintian, could you please confirm that
dh-elpa is not misusing Built-Using and will continue to use that field[1]?
Alternatively, there are other means to detecting maintscripts from
helpers (see the classification tag for
"debhelper-autoscript-in-maintainer-scripts")
Thanks,
~Niels
[1] My understanding is that Built-Using is designed to be a GPL
compliance tool rather than a metadata field describing what tooling was
used to compile the binary.
Reply to: