Am 28.02.23 um 21:48 schrieb Sam Hartman:
>> Moreover, I suspect in a number of the cases related to this
>> current bug, replaces will be likely. I suspect that in some of
>> the cases where units have been introduced that are disabled
>> currently, but will be enabled by the dh_installsystemd change,
>> we will discover we'd like those units disabled in some
>> configurations. A logical way to handle that may be to split out
>> the units into separate packages. That makes the replaces
>> interacts with file moves class of bugs more likely in this
>> situation than average.
Sebastian> The TC advice refers to files moving between packages
Sebastian> which wouldn't be the case here (at least not in
Sebastian> general).
Not in general, but I think that these systemd units will be more
likely than average to move packages.
These units have been sitting around more or less doing nothing for
months.
And in most cases we don't have bugs.
I'm imagining the following situation:
* We make the debhelper change
* unit b in package a starts running
* Users complain that they don't really always want that.
* We release
* unit b is moved back to /lib/systemd/system
* Later the complaints get serious enough that package a splits into a
and a-daemon, a-daemon replaces/breaks a<< version-of-split. a-daemon
now has b.
If a service is not supposed to be enabled, then an override for dh_installsystemd is the correct solution, setting --no-enable, but not by moving it into a subpackage.
I also don't see a good reason, why a unit file, once installed in /usr/lib/systemd/system should ever move back to /lib/systemd/system.
Michael
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature