Re: Policy consensus on transition when removing initscripts.
Hi,
On 6/28/23 02:31, Russ Allbery wrote:
Normally Conflicts is always added with Replaces because otherwise you can
have the following situation:
* Package A version 1.0-1 is installed providing file F.
* File F is moved to package B as of package A 1.0-3.
* User installs package B, which replaces the file in package A.
* User upgrades package A to version 1.0-2 (*not* 1.0-3). Or, rather,
tries, because this will fail with an error due to the file conflict.
No, that is fine. "Replaces: A (<< 1.0-3)" is sufficient here that the
file is not unpacked from A 1.0-2.
(Reading database ... 3 files and directories currently installed.)
Preparing to unpack A-2.deb ...
Unpacking a (2) over (1) ...
Replaced by files in installed package b (1) ...
Setting up a (2) ...
Debian packaging
is already hard enough; we should automate as much as we possibly can.
Nothing against automating it, but this doesn't need to be done
centrally, so I'd expect the orphan-sysvinit-scripts maintainers to set
up a cronjob or systemd timer[1] that checks for removed init scripts if
they felt that was necessary.
I don't see the need for mandating that automation for what is
essentially a very small transition that is low-impact and
well-supported by our existing tools, and doing so does not decrease the
workload on individual maintainers because they still need to look up
the appropriate action to take on removal of an init script even if that
action is "do nothing."
A
comprehensive checklist of everything you're supposed to think about when
packaging a Debian package doesn't exist (Policy is certainly shy of
that), and if it did, would form a hardcover book large enough to use as a
boat anchor.
We have an upgrade checklist for moving to a newer Standards-Version,
and we have the Developers' Handbook.
Simon
[1] probably not
Reply to: