Bug#883772: lintian: please don't map implimentation language to sections

[David Bremner]

Guillem Jover  writes:

> 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.

You classification seems plausible, and getting some ftp-master
documentation that reflected that would be a good start.

Unfortunately making distinction is not possible based on the package
name for elpa- packages.  Even making the distinction by hand is not so
easy. Consider the example of 'magit', which is an editor plugin that
probably belongs in either either "editors" or "version control" (or
realistically, both). On the other hand, it is a dependency of magithub,
and the elpa- naming is necessary for the dh_elpa tooling to work. I
think similar confusion exists in many other places in the
archive. `libapp-nopaste-perl` is in section perl, but its users don't
care that it's written in perl.

Unfortunately warnings with "certainty = possible" don't seem to be
interpreted as the lintian maintainers probably intended, as suggestions
requiring maintainer judgement. People just want to make their packages
"lintian clean".



signature.asc
Description: PGP signature

Bug#883772: lintian: please don't map implimentation language to sections

[Guillem Jover]

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  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] 

> 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

Bug#883772: lintian: please don't map implimentation language to sections

[David Bremner]

Package: lintian
Version: 2.5.59
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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).

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.

- -- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.29.1-6
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.4
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.4
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-7
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-2
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.26.1-3
ii  t1utils   1.41-1
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.4
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.47-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlopP28ACgkQ8gKXHaSn
nizzKAv/QGmFPyfIvCB5bJVOQyLj0qhaotCkGoZBapBEfXzQEYKvjvEDhEI+ANs2
xZeAXeJ+NWBAaPMQy8YvmHPS0kCUypXDCztd88L1eujm1II+NwnEBm2z/5UGZ5qZ
ZSHCsl1xbmmaGI0FN+O5D+TsDDcxs+iw2Kd0R3esakUzAkjYiUzMZIJfwiq78oL6
OtDIpT5U8uJJkzQo4M/UaETFUftqpzIu/68BRT1/nQpsQhtNuYJF3QMbmrAAl5ns
f3w1VMWuz+gExCZkUWfojMUyZxBNLJwldiDX2tk+WPYxgluvf0A23TJiYnjX26+S
W8xkZPilJS6MsUe27iROvK19kv1PtfQzXjRTwGjQ+pH2xGKdfV14PwTpugx4dt2B
/6rBIfBcvJV3r6OvGsWmbex2ZNA76LvG5WS6cBL3BycSLfNHLHn1F9TAS1jmnK9E
5SffMYmJtUKFt8HadlWXtpEIRlmH1m+n7yRWMWwQxtCKgz8LxWekbKljrIDYvtL0
/h5Dqd29
=MtWx
-END PGP SIGNATURE-