Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Chris Lamb]

tags 898136 + pending
thanks

Thanks all; removed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/fd56e1fc5f8bc4a43c9adfe6ab5958b6a762c042

  checks/fields.desc | 10 --
  checks/fields.pm   |  6 --
  debian/changelog   |  3 +++
  3 files changed, 3 insertions(+), 16 deletions(-)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Russ Allbery]

Paul Wise  writes:
> On Mon, 2018-05-07 at 19:27 -0700, Russ Allbery wrote:

>> I just now checked, and the packages currently diagnosed with this
>> tag [1] are 100% false positives, which makes me wonder if this tag
>> should just be deleted.

> I haven't confirmed this, but if true, go ahead.

For the record, the methodology I used was to assume that all the packages
with a specific MTA in the package name were not generic.  (Most of those
appear to be packages built by the same MTA source package, although a few
are plugins for specific MTAs.)  I then looked at the descriptions of all
remaining packages.  Each of them called out the specific MTA in their
description.

They all fell into two classes: either they were add-ons for a specific
MTA (mostly Postfix, although there was one exim4 add-on), or they were
virtual server managers or control panels or something similar that (per
the package description) could only configure specific MTAs (generally
Postfix).

-- 
Russ Allbery (r...@debian.org)   

Processed: Re: Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Debian Bug Tracking System]

Processing control commands:

> tags -1 - moreinfo
Bug #898136 [lintian] lintian: Reduce 
depends-on-mail-transport-agent-without-alternatives to pedantic
Removed tag(s) moreinfo.

-- 
898136: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898136
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Paul Wise]

Control: tags -1 - moreinfo

On Mon, 2018-05-07 at 19:27 -0700, Russ Allbery wrote:

> I looked at the original bug report from Paul Wise (cc'd) (#892144), and
> the motivation was unclear to me.  Were there packages in the archive that
> depended on only one MTA and weren't MTA add-ons or otherwise
> intentionally locked to just one MTA?

IIRC the motivation at the time was that I had found another MTA
related issue in the archive, filed a lintian bug about it, thought
about other MTA issues that might exist and filed #892144 about that.

> At first glance, the bug this tag is trying to diagnose seems unlikely to
> me.  I'm not sure how many maintainers intended to depend on a generic
> mail-transport-agent and just picked one out of a hat (although I admit
> the lack of documentation in Policy for how to declare this dependency
> doesn't help).  In contrast, add-ons for one specific MTA, or management
> interfaces that only know how to configure one specific MTA, are fairly
> common.

I didn't go over every package in the archive before filing the issue,
I think I might have wanted lintian.d.o to do that for me ;)

> I just now checked, and the packages currently diagnosed with this
> tag [1] are 100% false positives, which makes me wonder if this tag
> should just be deleted.
 
I haven't confirmed this, but if true, go ahead.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 898136 + moreinfo
Bug #898136 [lintian] lintian: Reduce 
depends-on-mail-transport-agent-without-alternatives to pedantic
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
898136: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898136
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Chris Lamb]

tags 898136 + moreinfo
thanks

Hi Russ,

> I just now checked, and the packages currently diagnosed with this tag [1]
> are 100% false positives, which makes me wonder if this tag should just be
> deleted.

Always possible. Let's let pabs chime in; tagging as moreinfo for now... :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Russ Allbery]

Chris Lamb  writes:

> Just to confirm; it currently it reports for all packages that provide
> mail-transport-agent, ie:

>   citadel-server
>   courier-mta
>   dma
>   esmtp-run
>   exim4
>   exim4-daemon-heavy
>   exim4-daemon-light
>   masqmail
>   msmtp-mta
>   nullmailer
>   opensmtpd
>   postfix
>   qmail-run
>   sendmail-bin
>   ssmtp

> .. and the suggestion is that this list is (essentially) reduced to
> just exim4?

> If so, I don't believe this would warrant the change in severity.

Some more research:

I looked at the original bug report from Paul Wise (cc'd) (#892144), and
the motivation was unclear to me.  Were there packages in the archive that
depended on only one MTA and weren't MTA add-ons or otherwise
intentionally locked to just one MTA?

I just now checked, and the packages currently diagnosed with this tag [1]
are 100% false positives, which makes me wonder if this tag should just be
deleted.

At first glance, the bug this tag is trying to diagnose seems unlikely to
me.  I'm not sure how many maintainers intended to depend on a generic
mail-transport-agent and just picked one out of a hat (although I admit
the lack of documentation in Policy for how to declare this dependency
doesn't help).  In contrast, add-ons for one specific MTA, or management
interfaces that only know how to configure one specific MTA, are fairly
common.

[1] 
https://lintian.debian.org/tags/depends-on-mail-transport-agent-without-alternatives.html

-- 
Russ Allbery (r...@debian.org)   

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Chris Lamb]

Hi Scott.


> Limiting it to packages that depend on exim4 would address all the false 
> positives I saw (since I mostly know about postfix stuff).

Just to confirm; it currently it reports for all packages that
provide mail-transport-agent, ie:

  citadel-server
  courier-mta
  dma
  esmtp-run
  exim4
  exim4-daemon-heavy
  exim4-daemon-light
  masqmail
  msmtp-mta
  nullmailer
  opensmtpd
  postfix
  qmail-run
  sendmail-bin
  ssmtp

.. and the suggestion is that this list is (essentially) reduced to
just exim4?

If so, I don't believe this would warrant the change in severity.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Scott Kitterman]

On Monday, May 07, 2018 01:35:30 PM Russ Allbery wrote:
> Scott Kitterman  writes:
> > Package: lintian
> > Version: 2.5.85
> > Severity: normal
> > 
> > Also, please reduce the certainty from certain.  It's not.
> > 
> > I'd just noticed depends-on-mail-transport-agent-without-alternatives.
> > I mainain approximately 10% of the packages affected by the check (3 of
> > 33) and in all those cases the check is wrong.  A cursory review of some
> > of the others clearly show it's incorrect for them as well (at least
> > 10).  I don't think a check with a false positive rate of a minimum of
> > nearly 50% is that useful.
> > 
> > In the case of my three, they depend on postfix without alternative
> > becuase they are only for postfix.
> 
> It sounds like there's both a bug and a certainty error here, but I don't
> think this check is a good example of something that should be pedantic.
> The dependency structure for depending on a generic MTA should be
> documented in Policy and only isn't because no one has found the time to
> write the patch.
> 
> A simple check for whether the depended-on MTA is also present in the name
> of the package would make a lot of these false positives go away.  If the
> package name contains "postfix" or "exim4" and depends on those MTAs, it's
> probably not a mistake.  :)
> 
> More generally, I suspect this tag should only affect packages that depend
> on the default (exim4).  If the package is already depending on a
> non-default MTA, I think it's highly likely that was intentional and
> Lintian is being more annoying than helpful here.
> 
> Pedantic isn't a dumping ground for buggy or uncertain checks.  If a check
> is known to be buggy or produce a lot of false positives but we don't want
> to delete it entirely because we think we can make it better in the
> future, that's what experimental is for.  Pedantic is for best-practice
> advice that's controversial, that is correct but may not be fixable (no
> upstream changelog, for instance), or that is minor
> quality-of-implementation details that a lot of maintainers aren't
> interested in messing with (upstream/metadata, for instance).

Thanks.  Experimental seems better.  Mostly I was thinking "not on the list of 
stuff most people see".  

I don't think that package name is a great trigger since, while many MTA 
specfic packages have the MTA name in the package name, not all do and there's 
no requirement for it.

Limiting it to packages that depend on exim4 would address all the false 
positives I saw (since I mostly know about postfix stuff).

Scott K

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Russ Allbery]

Scott Kitterman  writes:

> Package: lintian
> Version: 2.5.85
> Severity: normal

> Also, please reduce the certainty from certain.  It's not.

> I'd just noticed depends-on-mail-transport-agent-without-alternatives.
> I mainain approximately 10% of the packages affected by the check (3 of
> 33) and in all those cases the check is wrong.  A cursory review of some
> of the others clearly show it's incorrect for them as well (at least
> 10).  I don't think a check with a false positive rate of a minimum of
> nearly 50% is that useful.

> In the case of my three, they depend on postfix without alternative
> becuase they are only for postfix.

It sounds like there's both a bug and a certainty error here, but I don't
think this check is a good example of something that should be pedantic.
The dependency structure for depending on a generic MTA should be
documented in Policy and only isn't because no one has found the time to
write the patch.

A simple check for whether the depended-on MTA is also present in the name
of the package would make a lot of these false positives go away.  If the
package name contains "postfix" or "exim4" and depends on those MTAs, it's
probably not a mistake.  :)

More generally, I suspect this tag should only affect packages that depend
on the default (exim4).  If the package is already depending on a
non-default MTA, I think it's highly likely that was intentional and
Lintian is being more annoying than helpful here.

Pedantic isn't a dumping ground for buggy or uncertain checks.  If a check
is known to be buggy or produce a lot of false positives but we don't want
to delete it entirely because we think we can make it better in the
future, that's what experimental is for.  Pedantic is for best-practice
advice that's controversial, that is correct but may not be fixable (no
upstream changelog, for instance), or that is minor
quality-of-implementation details that a lot of maintainers aren't
interested in messing with (upstream/metadata, for instance).

-- 
Russ Allbery (r...@debian.org)   

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Scott Kitterman]

Package: lintian
Version: 2.5.85
Severity: normal

Also, please reduce the certainty from certain.  It's not.

I'd just noticed depends-on-mail-transport-agent-without-alternatives.  I
mainain approximately 10% of the packages affected by the check (3 of 33) and
in all those cases the check is wrong.  A cursory review of some of the others
clearly show it's incorrect for them as well (at least 10).  I don't think a
check with a false positive rate of a minimum of nearly 50% is that useful.

In the case of my three, they depend on postfix without alternative becuase
they are only for postfix.

Scott K