Hello,

On Thu 16 Aug 2018 at 04:29PM +0200, Axel Beckert wrote:

>> The assumption that the binary package is called elpa-foo (where is foo
>> is deduced from the package.el metadata) is baked into dh-elpa at a
>> pretty deep level. The assumption is that you will make a seperate
>> binary package for the emacs stuff.
>
> Yeah, that's what I feared and what I consider to be a bug.
>
>> So I guess this bug could be considered a feature request to support
>> a different use-case.
>
> That's another possible way to see it. But in that case, the lintian
> warning emacsen-common-without-dh-elpa
> (https://lintian.debian.org/tags/emacsen-common-without-dh-elpa.html)
> is definitely having the wrong Severity and Certainty.

I disagree that there is anything to be fixed in Lintian.  I am keen
that the severity and certainty remain such that Lintian emits this tag
at the level of a warning (i.e. I don't mind if the values of Severity
and Certainty get changed so long as the tag is still a warning).

There is a consensus on the Emacs team that all Emacs lisp in Debian,
outside of that included in Emacs itself, should eventually be shipped
in elpa-* binary packages that contain only Emacs lisp.  We do not
consider tiny binary packages to be a problem, and I do not believe that
the FTP Team does either, in 2018.  In the past few months we have
uploaded tens of tiny binary packages as part of breaking up
emacs-goodies-el, for example, and all have gone through NEW.

As such, the tag is correct: it reflects the Emacs team's consensus view
that all source packages that have Emacs lisp to install should install
it in its own binary package using dh_elpa.  The tag communicates that
consensus to package maintainers outside of the team.

Of course, a package maintainer can disagree with that consensus, and
override or ignore the tag.  This does not seem like sufficient reason
to downgrade the level at which the tag is emitted.  Overriding tags is
not particularly costly, but the cost of downgrading the tag might be
significant.  Using dh_elpa is not just "nice to have" -- the
maintainability advantages for Debian as a whole are significant.  We
need maintainers to be made aware of that.

> Given that your "baked into dh-elpa at a pretty deep level" sounds as
> if this is neither easy to fix nor will this come soonish, this
> lintian tag should be:
>
> [...]
>
> b) changed from "Certainty: certain" to "Certainty: wild-guess" as
>    there are clearly multiple and common cases where the switch to
>    dh-elpa is impossible as of now.

I do not know of any cases other than wanting to retain XEmacs support,
but XEmacs is unmaintained upstream, so such cases will disappear from
Debian in the next few years.  Do you perhaps refer to the "common case"
of not wanting a tiny binary package?  I am not sure it is so common :)
Please let me know the multiple and common cases you have in mind here.

> Alternatively, the tag should be changed to be only emitted if the
> binary package is named either elpa-*, *-el or *-mode, i.e. clearly
> being a package which only ships some Emacs plugin and nothing else.
> (Not sure if there are better criterias for the according whitelist.)

This would defeat a lot of the purpose of the tag.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply via email to