Bug#883772: lintian: please don't map implimentation language to sections
Hi!
On Thu, 2017-12-07 at 09:17:43 -0400, David Bremner wrote:
> As summarized in
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802488
>
> the programming-language sections are a mess. It's not clear why the
> user cares about the implimentation language when looking for a
> package, so encouraging maintainers to move packages from sections
> that relate to the use of a package (e.g. mail) to one based on the
> implimentation language (e.g. lisp), is actively destructive (albeit
> in a minor way).
Certainly, and that's what I've been following when filing my mass
override fixes to ftp-masters.
> The specific case that's annoying me is the 'elpa-*' -> section lisp
> mapping added in c85f00e3. There's an argument that all emacs
> extensions belong in section "editors" (where i believe the vim
> extensions are). Or, if you think emacs as more of an application
> platform, then emacs based mail-readers belong with other mail
> readers, emacs based irc-clients belong with other irc clients, and so
> on. Even if we care about implimentation language (or more defensibly,
> grouping extensions together) forcing all elpa-* into section lisp
> doesn't help anything; the package name already carries more
> information than the section.
Right, that was my mistake, I assumed these were generic lisp modules,
just coming from an external module registry similar to CPAN, CTAN and
similar. If these are instead more like plugins than modules
(automatically depended on by other package) then indeed these do not
belong in the lisp section at all. I'll prepare a fix for this.
On Fri, 2018-01-12 at 21:47:06 -0400, David Bremner wrote:
> Chris Lamb <lamby@debian.org> writes:
> >> the programming-language sections are a mess
> >
> > Whilst I don't necessarily disagree, I'm not sure what the next steps
> > for Lintian are here.
> >
> > Putting it another way, I see you linked #802488 but until that gets
> > some kind of resolution (or some change to Policy), what is there for
> > us to do..?
The organization of the archive has always been in the hands of
ftp-masters. Policy might need to be updated, perhaps to reflect
ftp-masters decisions here, not the other way around. It's worth
noting that the Section and Priority override used to be an essential
part of the NEW processing, which unfortunately I've got the feeling
it is not being done for a long time now at least for the Section field. :(
Some time ago I tried to discuss and clarify the Section organization
with ftp-masters, but there was unfortunately no much reaction, since
then I wrote a tool [O] to help me track and send mass override fixes
out of my own criteria, which seems to get applied w/o complain.
[O] <https://namespace.hadrons.org/arsenal/overrides-sublimator>
> Let me turn that question around. In the absence of clear policy [1] of what
> belongs in the programming language sections, why should lintian
> recommend adding things to them? At best it's busywork for maintainers
> and ftp-masters, and at worst it's making things worse for our users [2].
TBH I think the distinction here is clear (at least to me), language-
specific sections should *only* contain things that are language specifc
modules that are automatically depended on, and language-specific
toolchains and similar. But nothing for which the language is just an
implementation detail.
On Sat, 2018-01-13 at 10:38:12 +0530, Chris Lamb wrote:
> > In case you consider the previous not constructive ;), what about
> > lowering the severity to "pedantic"?
>
> Again, I share your opinion about the entire section thing, just that
> a bug against Lintian is the best forum for such a discussion :) Lets
> downgrade it from "W" to "I" at the very least:
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=07bc5dff9aa74e738a24b50b30a2dd8ea103ac27
I'd rather we fixed the actual problem here with elpa, instead of
lowering it from W to I. In addition to my mass overrides, I was happy
to see that we could slowly course-correct the Section degradation via
lintian, but lowering this, makes it more difficult. :(
Thanks,
Guillem
Reply to: