[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

>>>>> "Russ" == Russ Allbery <rra@debian.org> 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

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.

Attachment: signature.asc
Description: PGP signature

Reply to: