Re: Is it the job of Lintian to push an agenda?

[Adam Borowski]

On Sun, Jul 14, 2019 at 09:21:37AM -0400, Theodore Ts'o wrote:
> but as saying goes, "patches gratefully accepted".  Whining for developers
> to do extra work via Debian Policy is, well, not.

If patches are actually accepted, that's fine.

But this Policy item currently servers as a tool to _sometimes_ get a patch
through.  In some cases such patches get stonewalled, and if you _then_ NMU
a package in question, you can get calls for getting demoted from DD.

We released Buster basically useless in GUI mode in !systemd, despite a
solution been discussed[1] and _implemented_ in January 2018, with multiple
later submissions.  And it's not that they haven't been noticed -- the
existence of that patchset was used to justify removal of (unlamented) shim.

So even that on-paper severity is not enough to get patches accepted.
Without it, regressions would be even worse.


Meow!

[1]. Only one member of the systemd team was helpful, so this can't be
called consensus on their part -- but not for a lack of trying.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ NADIE anticipa la inquisición de españa!
⠈⠳⣄

Re: Is it the job of Lintian to push an agenda?

[Theodore Ts'o]

On Sun, Jul 14, 2019 at 11:10:36AM -0300, Chris Lamb wrote:
> Theodore Ts'o wrote:
> 
> > P.S.  I'm going to be adding an override in e2fsprogs for
> > package-supports-alternative-init-but-no-init.d-script because it
> > has false positives
> 
> Regardless of the specifics of this particular package if Lintian
> could feasibly not emit this false-positive, would it surely not be
> more sensible to get this fixed there instead?

There is a bug open against Lintian already, but it's not at all clear
it's solveable short of solving the halting problem.  E2fsprogs is
shipping 5 systemd unit files for which the cron.d file is a rough
substitute.  So the only choice is whether you want false positive or
false negative reports for a Lintian "Important" warning.

I'm getting 5 Important Lintian errors, one for each systemd unit
files.  Some of them are associated with a systemd.timer setup, and
some are normal system services unit files.  *All* of them in
combination implement the functionality which is also (mostly)
provided by cron.d entry and the e2scrub_all_cron shell script.

Just suppressing the warning for systemd.timer files would not be
sufficient.  You'd have to suppress *all* Lintian complaints of this
class if there is at least one timer file and at least one cron.d file
in the package.   But that's going to subject to false negatives.

Or, you know, you could solve the halting problem.  :-)

> That would not only be a cleaner solution than an override (which you
> would likely just have to remove later...) it would be a general
> kindness in that it could potentially save countless other developers
> undergoing the same manual process as you.

I prefer not to either (a) delay a release of e2fsprogs until this
Lintian bug is solved, one way or another (and it's not clear it can
be solved easily), or (b) deal with people complaining and filing bugs
regarding the Lintian Important report.

So override does seem to be the best approach, especially given how
charged the whole sysvinit vs systemd controversy and my lack of faith
that the Lintian bug is going to be resovled any time soon.  I'd
*much* rather avoid any flames directed at me caused by this false
positive.

  - Ted

Re: Is it the job of Lintian to push an agenda?

[Russ Allbery]

Sam Hartman  writes:
>> "Ansgar" == Ansgar Burchardt  writes:

> Ansgar> If we have no consensus that doing something is the right
> Ansgar> thing, then lintian should probably not start raising a
> Ansgar> warning about it and one should keep in mind that Policy
> Ansgar> might not reflect consensus when referring to it.

> When the policy decision was made, I think we did have consensus.

> So, no, that's our current policy at least until something changes it.

For the record, this is exactly the way that I view it as well.

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

Re: Is it the job of Lintian to push an agenda?

[Chris Lamb]

Theodore Ts'o wrote:

> P.S.  I'm going to be adding an override in e2fsprogs for
> package-supports-alternative-init-but-no-init.d-script because it
> has false positives

Regardless of the specifics of this particular package if Lintian
could feasibly not emit this false-positive, would it surely not be
more sensible to get this fixed there instead?

That would not only be a cleaner solution than an override (which you
would likely just have to remove later...) it would be a general
kindness in that it could potentially save countless other developers
undergoing the same manual process as you.

> It most *definitely* is not certain.

Again, this sounds like something trivially addressed in Lintian
itself, or perhaps even by not reading too much into this apparently
entirely-adjunct advisory classification that is, after all, not
central to Lintian's operation.


Best wishes,

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

Re: Is it the job of Lintian to push an agenda?

[Chris Lamb]

Jérémy Lal wrote:

> "Is it the job of Lintian to push an agenda?"
> is a good question, and it would be nice to get a general answer,
> separately from the technical issue about sysvinit scripts.

Difficulties are always inherent in shipping any opinionated linter to
people with a wide spectrum of motivations and ideas. Furthermore, if
it becomes pervasive then there is not only a risk of its output being
followed without attention, when interpreted as a kind of de-facto
policy there is an additional a danger of it being beaten from a
plowshare back into a sword on contentious issues.

As the first line of defense to the above, Lintian reflects the
positions taken and espoused in our official Policy and should [0]
always defer to that esteemed text.

It therefore follows that if the Debian Policy decrees a certain
direction and Lintian mirrors that then in the rare cases of dissent
or disagreement the right and proper course of action is to re-raise
it via Policy and its various appeal processes. If that is not
possible then that is a regrettable state of affairs, but Lintian is
not the venue to stage one's passive-aggressive proxy war on
controversial and highly-charged issues within Debian and its
maintainers have neither the strength, stomach nor spoons for such
maneuevers.

As Sean implies in an adjacent message, all of the above is compounded
by there being a number of recommendations that are considered to be
good practice by most [1] but are not part of Policy (and most should
or can never be). Lintian's various severity levels ("E:", "W:", "I:",
etc), as well as responding to cordial and reasonable requests to
adjust these do allow it to address, albeit extremely clumsily, the
extremely wide spectrum involved here.

As a postscript, it seems like the term "agenda" was a regrettable
choice for this thread given that it carries an implication of
underhanded and dishonest motives. As I am certain that would never be
the intention of my dear colleagues, to avoid any possible
misinterpretations for the remainder of my message I have adopted
alternative terms instead.

  [0] Or, if you may excuse an RFC2119 pun, "MUST"...
  [1] Feel free to dilute to taste with similar terms.


Regards,

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

Re: Is it the job of Lintian to push an agenda?

[Theodore Ts'o]

On Sat, Jul 13, 2019 at 02:22:01PM -0700, Russ Allbery wrote:
> Matthias Klumpp  writes:
> 
> > With two Debian stable releases defaulting to systemd now, I think a
> > solid case could be made to at least relax the "must" requirement to a
> > "should" in policy (but that should better go to the respective bug
> > report).
> 
> The Policy process is not equipped to deal with this because that process
> requires fairly consensus, and I don't believe that's possible to reach on
> this topic.
> 
> I don't know what decision-making process the project should use here: a
> big thread on debian-devel (wow, that sounds fun), a bunch of in-person
> conversations at DebConf (probably way more productive but excludes some
> folks), the TC (tried and didn't work very well), a GR, some new mediated
> consensus process, or what.  Or maybe some working group that goes all-in
> on creating a "good enough" automated translation from unit files to
> sysvinit scripts and we support sysvinit that way and thereby dodge the
> problem.

The alternative seems to be a large number of package maintainers
willfuly ignoring a particular reading of the Policy, whether or not
that reading of the policy is "correct" or not.  Hopefully we can
avoid bug priority escalation/descalation wars over what might or
might not be a policy violation.   Oh joy

- Ted

P.S.  I'm going to be adding an override in e2fsprogs for
package-supports-alternative-init-but-no-init.d-script because it
has false positive, regardless of its claim:

N:Severity: important, Certainty: certain

It most *definitely* is not certain.  We went through quite a bit of
trouble providing alternative functionality via cron, and not via
(only) systemd timers.  I will admit the functionality is slightly
better if you are using systemd, but as saying goes, "patches
gratefully accepted".  Whining for developers to do extra work via
Debian Policy is, well, not.

And I say all of this not being a systemd fan.  But the vast majority
of Linux ecosystem has made a choice, and we should just move *on*.

Re: Is it the job of Lintian to push an agenda?

[Sam Hartman]

> "Ansgar" == Ansgar Burchardt  writes:

Ansgar> Russ Allbery writes:
>> Matthias Klumpp writes:
>>> With two Debian stable releases defaulting to systemd now, I
>>> think a solid case could be made to at least relax the "must"
>>> requirement to a "should" in policy (but that should better go
>>> to the respective bug report).
>> 
>> The Policy process is not equipped to deal with this because that
>> process requires fairly consensus, and I don't believe that's
>> possible to reach on this topic.

Ansgar> If we have no consensus that doing something is the right
Ansgar> thing, then lintian should probably not start raising a
Ansgar> warning about it and one should keep in mind that Policy
Ansgar> might not reflect consensus when referring to it.

When the policy decision was made, I think we did have consensus.

So, no, that's our current policy at least until something changes it.
The processes I'm aware of for changing policy absent a consensus to do
so are GR and TC.

--Sam

Re: Is it the job of Lintian to push an agenda?

[Ansgar Burchardt]

Russ Allbery writes:
> Matthias Klumpp writes:
>> With two Debian stable releases defaulting to systemd now, I think a
>> solid case could be made to at least relax the "must" requirement to a
>> "should" in policy (but that should better go to the respective bug
>> report).
>
> The Policy process is not equipped to deal with this because that process
> requires fairly consensus, and I don't believe that's possible to reach on
> this topic.

If we have no consensus that doing something is the right thing, then
lintian should probably not start raising a warning about it and one
should keep in mind that Policy might not reflect consensus when
referring to it.

Ansgar

Re: Is it the job of Lintian to push an agenda?

[Sean Whitton]

Hello,

On Sat 13 Jul 2019 at 11:10PM +02, Jérémy Lal wrote:

> the question
> "Is it the job of Lintian to push an agenda?"
> is a good question, and it would be nice to get a general answer,
> separately from the technical issue about sysvinit scripts.

I think that it is useful to Debian for Lintian to be a bit more
opinionated, and a bit less conservative, than Policy is.

Especially if you turn on all the tag levels, Lintian pushes a fairly
strong set of ideas about what packages should look like.  Most everyone
will find something they disagree with, but it gets us to think about
these things and consider whether they might be good ideas.  Over time,
tags can get turned down in severity or changes can make their way into
the Policy Manual.

Of course, if Lintian gets too far "ahead" of Policy then it would be
less useful.  What I think is useful to us is for it to be just a little
bit more pushy than Policy, as indeed it is.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Is it the job of Lintian to push an agenda?

[Sean Whitton]

Hello,

On Sat 13 Jul 2019 at 02:22PM -07, Russ Allbery wrote:

> Matthias Klumpp  writes:
>
>> With two Debian stable releases defaulting to systemd now, I think a
>> solid case could be made to at least relax the "must" requirement to a
>> "should" in policy (but that should better go to the respective bug
>> report).
>
> The Policy process is not equipped to deal with this because that process
> requires fairly consensus, and I don't believe that's possible to reach on
> this topic.
>
> I don't know what decision-making process the project should use here: a
> big thread on debian-devel (wow, that sounds fun), a bunch of in-person
> conversations at DebConf (probably way more productive but excludes some
> folks), the TC (tried and didn't work very well), a GR, some new mediated
> consensus process, or what.  Or maybe some working group that goes all-in
> on creating a "good enough" automated translation from unit files to
> sysvinit scripts and we support sysvinit that way and thereby dodge the
> problem.
>
> But, and I'm putting my Policy Editor delegate hat on to say this, I
> believe the Policy process is the wrong tool to use here because it will
> not converge.  (That said, Sean, as the other Policy Editor delegate,
> should feel free to disagree if he thinks I'm wrong.)

Just to note that I'm in agreement with Russ on this.  While things may
well change in the future (either the project's opinion on init or the
way Policy works), Policy is not the way to do this for the time being.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Is it the job of Lintian to push an agenda?

[Russ Allbery]

Russ Allbery  writes:

> The Policy process is not equipped to deal with this because that
> process requires fairly consensus, and I don't believe that's possible
> to reach on this topic.

Argh.  That should have been "fairly strong consensus" and fell victim to
last-minute editing.

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

Re: Is it the job of Lintian to push an agenda?

[Russ Allbery]

Matthias Klumpp  writes:

> With two Debian stable releases defaulting to systemd now, I think a
> solid case could be made to at least relax the "must" requirement to a
> "should" in policy (but that should better go to the respective bug
> report).

The Policy process is not equipped to deal with this because that process
requires fairly consensus, and I don't believe that's possible to reach on
this topic.

I don't know what decision-making process the project should use here: a
big thread on debian-devel (wow, that sounds fun), a bunch of in-person
conversations at DebConf (probably way more productive but excludes some
folks), the TC (tried and didn't work very well), a GR, some new mediated
consensus process, or what.  Or maybe some working group that goes all-in
on creating a "good enough" automated translation from unit files to
sysvinit scripts and we support sysvinit that way and thereby dodge the
problem.

But, and I'm putting my Policy Editor delegate hat on to say this, I
believe the Policy process is the wrong tool to use here because it will
not converge.  (That said, Sean, as the other Policy Editor delegate,
should feel free to disagree if he thinks I'm wrong.)

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

Re: Is it the job of Lintian to push an agenda?

[Jérémy Lal]

Hi,

the question
"Is it the job of Lintian to push an agenda?"
is a good question, and it would be nice to get a general answer,
separately from the technical issue about sysvinit scripts.

Jérémy

Re: Is it the job of Lintian to push an agenda?

[Matthias Klumpp]

Am Sa., 13. Juli 2019 um 22:04 Uhr schrieb Vincent Bernat :
>
>  ❦ 13 juillet 2019 11:52 -07, Russ Allbery :
>
> >> Previously, we had a sort of agreement (through the TC decision) that
> >> such scripts should be maintained by people caring about them and we
> >> should only act on bug reports with proper patches to have them.
> >
> > I don't agree that this was ever the agreement.
>
> I was referring to
>  but it seems
> it only applies to non-SysV init script, my bad.
>
> I am still unhappy with the situation, but I don't think it is worth
> arguing about it as I am pretty sure it will have no impact whatsoever.

What will have an impact is moving
 forward, I
guess.
Writing init scripts for sysvinit is a massive amount of work for
non-simple cases, and my own software as well as other software
projects don't actually ship sysvinit scripts anymore (simply because
testing them just isn't worth the time and effort if you can actually
achieve what you wanted easier).
While I think it's fair to request from package maintainers to merge
compatibility scripts for sysvinit, forcing them to write sysvinit
scripts while our default init systemd is systemd and where even
testing those scripts is a major pain is IMHO not.
There was a long discussion on not-shipping / dropping sysvinit
scripts in a request to the TC in 2016
, I am
assuming you meant that when talking about a TC ruling. No decision
was made there though, and normal policy processes should resolve
this.
With two Debian stable releases defaulting to systemd now, I think a
solid case could be made to at least relax the "must" requirement to a
"should" in policy (but that should better go to the respective bug
report).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Is it the job of Lintian to push an agenda?

[Vincent Bernat]

 ❦ 13 juillet 2019 11:52 -07, Russ Allbery :

>> Previously, we had a sort of agreement (through the TC decision) that
>> such scripts should be maintained by people caring about them and we
>> should only act on bug reports with proper patches to have them.
>
> I don't agree that this was ever the agreement.

I was referring to
 but it seems
it only applies to non-SysV init script, my bad.

I am still unhappy with the situation, but I don't think it is worth
arguing about it as I am pretty sure it will have no impact whatsoever.
-- 
Modularise.  Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Is it the job of Lintian to push an agenda?

[Niels Thykier]

Russ Allbery:
>> Thanks to this new Lintian tag, the current situation is that packages
>> won't pass NEW without a SysV init script (unless a FTP-masters ignore
>> this specific tag despite its severity).
> I haven't worked on Lintian in several years, so perhaps my information is
> stale, but at least previously ftp-master rejects were not based on
> severity, but rather on a hard-coded list of tags maintained by
> ftp-master.

For reference, Russ is correct.  For the people curious about the
concrete tags, please see [1].

Thanks,
~Niels

[1] https://ftp-master.debian.org/#lintianrejects

Re: Is it the job of Lintian to push an agenda?

[Scott Kitterman]

On Saturday, July 13, 2019 2:52:59 PM EDT Russ Allbery wrote:
> Vincent Bernat  writes:
> > Thanks to this new Lintian tag, the current situation is that packages
> > won't pass NEW without a SysV init script (unless a FTP-masters ignore
> > this specific tag despite its severity).
> 
> I haven't worked on Lintian in several years, so perhaps my information is
> stale, but at least previously ftp-master rejects were not based on
> severity, but rather on a hard-coded list of tags maintained by
> ftp-master.

That's correct.  We do also do a general review of the package and lintian 
feedback is one thing we do consider.  Personally, I don't recall having 
rejected a package for this.  I believe I have accepted a few and then filed a 
bug (even prior to the lintian check).

Scott K

Re: Is it the job of Lintian to push an agenda?

[Russ Allbery]

Vincent Bernat  writes:

> Lintian got a new tag to enforce Policy 9.11:

>  Packages may integrate with these replacement init systems by
>  providing implementation-specific configuration information
>  about how and when to start a service or in what order to run
>  certain tasks at boot time. However, any package integrating
>  with other init systems must also be backwards-compatible with
>  sysvinit by providing a SysV- style init script with the same
>  name as and equivalent functionality to any init-specific job,
>  as this is the only start-up configuration method guaranteed to
>  be supported by all init implementations.

Policy 9.11 and this provision were introduced in Policy 3.9.4, which was
published in August of 2012.  I'm therefore very confused by this
statement:

> As usual with a policy change, it will take years.

since this is not a recent Policy change (in fact, prior to this section
of Policy there was no documentation of support for any init system
*other* than sysvinit), and it's *been* years.  So far as I can tell, the
only thing that's new is the Lintian tag.  Lintian aspires to testing as
much of Policy as possible, so my baseline assumption would be that
someone contributing to Lintian just got around to doing the
implementation work.

The Policy provision is, as you noted in the bug references I snipped,
arguably buggy in that it doesn't clarly allow for systemd units that
should not or cannot correspond to init scripts, and it could definitely
use some tweaking (as, possibly, could the Lintian tag), but the base
requirement for providing a corresponding sysvinit init script to start a
daemon that is started via a systemd unit file is not new and has been the
Policy requirement since before systemd became the default init system.

> Some people will push back and the result is that a few people can
> impose to everyone else the additional work to maintain SysV init
> script.

Continued support for sysvinit has been the consensus of the project since
the systemd debate.  We can, of course, change that, but *that* would be
the change, not this.

> Previously, we had a sort of agreement (through the TC decision) that
> such scripts should be maintained by people caring about them and we
> should only act on bug reports with proper patches to have them.

I don't agree that this was ever the agreement.

> Thanks to this new Lintian tag, the current situation is that packages
> won't pass NEW without a SysV init script (unless a FTP-masters ignore
> this specific tag despite its severity).

I haven't worked on Lintian in several years, so perhaps my information is
stale, but at least previously ftp-master rejects were not based on
severity, but rather on a hard-coded list of tags maintained by
ftp-master.

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