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
signature.asc
Description: PGP signature
