>> 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.
* Now we have a potential problem where we have both a file move and a
replaces, and b can disappear on an upgrade from a pre-split a to
a+a-daemon after the split.
Whether that happens depends on dpkg's order of operations
The nasty thing about this situation is that moving b from /usr to /
can happen at very different points in the release cycle from doing the
split and adding the replaces.
You need to remember whether during the release cycle you've had any
moves that can involve aliased paths.
If you have, you must not later in the release cycle introduce replaces.
So, in general, we'll be fine. But in specific I don't think we'll be
fine that removing the debhelper code will be a sane thing to do.
signature.asc
Description: PGP signature
