Sam Hartman <hartm...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>