Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Sam Hartman <hartmans@debian.org> 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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: