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
