Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sean Whitton]

Hello,

On Mon 28 Dec 2020 at 12:24AM +01, gregor herrmann wrote:

> On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote:
>
>> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
>> > My reasoning is that init scripts are the end goal, and that elogind is
>> > just a symptom of that end goal, and that therefore talking about
>> > elogind in isolation serves no purpose.
>> The GR specifically mentions elogind and not init scripts.
>
> "Technologies /such as/ elogind …" (emph. mine) shows to me that this
> is meant as an example, as a "demonstration", and not as an
> exhaustive list [0]. So neither is elogind "special" nor is it the
> only relevant piece of software to consider supporting. [1]

Yes, fair enough, thanks.

I think what is more relevant is that hard Depends: are harder to work
around than being asked to move files between coinstallable packages.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> We do drop features all the time between stable releases,
Russ> though, and generally that too is at the maintainer's
Russ> discretion.  The package maintainer's normal obligation in
Russ> Debian isn't to keep everything working that previously was
Russ> working, but to make it obvious when something is incompatible
Russ> (ideally before it breaks on a given system in a way that's
Russ> hard to back out of).

Agreed.

Russ> Often this is done by dropping or
Russ> renaming packages so that the old package just has no upgrade
Russ> path, but we handle it in other ways as well (release notes,
Russ> NEWS.Debian, etc., depending on the severity of the
Russ> incompatibility).

Agreed.
I think a reasonable way for the TC to handle the init script part of
this bug might be to politely suggest to the maintainer that they
include a note in the release notes.
(Or for a member of the TC to just propose such a note to the release
notes maintainers).
Russ> I guess the summary of my position on init scripts
Russ> specifically is that I generally agree with Wouter's framing
Russ> of two approaches to Debian who want very different things,
Russ> and I thought (at least for init scripts) we put a range of
Russ> options on the table from "you must support both approaches"
Russ> to "we're only going to support one approach," and the option
Russ> that people chose is "one option is strongly preferred but
Russ> individual maintainers can support other approaches if they
Russ> want to and we don't want to make exploration of other
Russ> approaches impossible."  The implication was that some
Russ> individual maintainers *won't* want to support other
Russ> approaches in their individual packages, and that's a decision
Russ> they get to make, and therefore folks who want to keep
Russ> sysvinit working should be exploring options that don't
Russ> require the maintainer incorporate that support (such as a
Russ> separate package of init scripts or a conversion utility that
Russ> generates init scripts from unit files).

We are in agreement here.  I guess that's not surprising given how many
times we have discussed this:-)

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Russ Allbery]

Sam Hartman  writes:

> The issue that came up in the policy discussion is that there may be
> implications for removing an init script.  As an example upgrades may
> break.  In the case of NetworkManager, you might find on an upgrade from
> buster to bullseye that you no longer have network because the init
> script disappeared.

> My recollection of the policy discussion is that there was a sense that
> we might want to say something about that if we managed to come up with
> a consensus, but we didn't want to block that on the general case.

> My take is that removing an init script is unambiguously okay under
> current policy as far as our policy on init scripts.  But for example,
> we have a rule that is fairly basic to our community that we don't break
> upgrades, or at least we try hard not to.  And it may well be that the
> TC or policy process could say more on that topic.

We do drop features all the time between stable releases, though, and
generally that too is at the maintainer's discretion.  The package
maintainer's normal obligation in Debian isn't to keep everything working
that previously was working, but to make it obvious when something is
incompatible (ideally before it breaks on a given system in a way that's
hard to back out of).  Often this is done by dropping or renaming packages
so that the old package just has no upgrade path, but we handle it in
other ways as well (release notes, NEWS.Debian, etc., depending on the
severity of the incompatibility).

That's what I took away from the point about not breaking upgrades.  I
think I may have interpreted "break" somewhat more narrowly than others,
given that.  To me, a broken upgrade is one in which the system stops
working without warning or loses data or the like.  If a package that used
to support MySQL and PostgreSQL now only supports PostgreSQL, that isn't a
"broken" upgrade as long as it's clearly advertised (in NEWS.Debian, in
release notes, etc.) and as long as it doesn't do something destructive
when it was previously using MySQL.

For example, one way that I would consider valid as a way to prevent
upgrades from breaking when one drops support for init systems that don't
support unit files would be to declare a dependency on the class of init
systems that do support unit files, so someone upgrading their system will
clearly see that they have to switch init systems or the package won't
work.  (This works particularly well if that's a change that apt will
decline to perform without special intervention.)  I think that's within
the normal sort of thing that package maintainers do when there are
incompatible changes to a package between stable releases.

I guess the summary of my position on init scripts specifically is that I
generally agree with Wouter's framing of two approaches to Debian who want
very different things, and I thought (at least for init scripts) we put a
range of options on the table from "you must support both approaches" to
"we're only going to support one approach," and the option that people
chose is "one option is strongly preferred but individual maintainers can
support other approaches if they want to and we don't want to make
exploration of other approaches impossible."  The implication was that
some individual maintainers *won't* want to support other approaches in
their individual packages, and that's a decision they get to make, and
therefore folks who want to keep sysvinit working should be exploring
options that don't require the maintainer incorporate that support (such
as a separate package of init scripts or a conversion utility that
generates init scripts from unit files).

Obviously (I hope) if a maintainer did take the dependency approach
mentioned above, there must be some straightforward path for a collection
of init scripts or a conversion utility to satisfy that dependency.
That's where the "project supports the efforts of developers working on
such technologies" part of the GR result comes in.

Just to be extremely clear, the dependency structure for logind feels
different to me and I don't have an opinion on that.

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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Vincent Bernat]

 ❦ 28 décembre 2020 10:32 -05, Sam Hartman:

> But  for example, we have a rule that is fairly basic to our community
> that we don't break upgrades, or at least we try hard not to.

This is becoming harder and harder because we pile more and more choices
(init choice, initramfs choice, merged-usr choice). This is becoming
less and less relevant as more and more people are using containers or
disposable VM and upgrade is not a requirement anymore.

At some point, we have to become leaner.
-- 
The secret source of humor is not joy but sorrow; there is no humor in Heaven.
-- Mark Twain

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> I think this clearly and unambiguously says that maintainers
Russ> can depend on unit support and drop init scripts from their
Russ> packages if they so choose, and that this choice only requires
Russ> as much justification as rejecting any other patch or feature
Russ> in their packages (and Debian is generally defers to package
Russ> maintainers here).

Russ> Apparently we still, after all that discussion, weren't on the
Russ> same page about this?  That's really unfortunate, since that
Russ> was one of the major questions on which we were trying to get
Russ> closure.

I'd like to be more optimistic.

during the policy discussion that led to the language you quoted later
in your message, we realized that

1) Do I need to include an new init script in a package

is a different question than

2) Should I drop an init script that already exists.

I think that the GR and policy discussion are unambiguous that
maintainers can (but need not) add an init script if they like.
A maintainer could for example reject an init script saying "I don't
want to spend the disk space, or I don't want to test that."

The issue that came up in the policy discussion is that there may be
implications for removing an init script.  As an example upgrades may
break.  In the case of NetworkManager, you might find on an upgrade from
buster to bullseye that you no longer have network because the init
script disappeared.

My recollection of the policy discussion is that there was a sense that
we might want to say something about that if we managed to come up with
a consensus, but we didn't want to block that on the general case.

My take is that removing an init script is unambiguously okay under
current policy as far as our policy on init scripts.
But  for example, we have a rule that is fairly basic to our community
that we don't break upgrades, or at least we try hard not to.
And it may well be that the TC or policy process could say more on that
topic.

Which is to say that I think in a specific case there might be a reason
why removing some init script that already existed would be a bad idea
even if we're agreed that no one has to add new init scripts unless they
want to.


signature.asc
Description: PGP signature