I have a question about python single-spec packaging.
[tl;dr: systemd targetcli service goes from enabled to disabled during
Quite a while ago I had to upgrade the "targetcli-fb" package in SLES
At that time, "single spec" was being heavily pushed, even though I
would just as soon written a single package and SPEC file for python3.
I spent quite a bit of time on the change. It turns out you have to have
duplicate ("alternative") copies of everything in your
python3-vs-python2 packages, so that they can co-exist, using
single-spec. When I complained that I didn't need two version of things
like man pages and systemd service files, I was told I should break my
package into a "common" part (not python version dependent) and a
python-version-dependent part. So with a bit of work I did that.
So now targetcli-fb became two new packages: python3-targetcli-fb
(assuming python3) and targetcli-fb-common.
The "python3-targetcli-fb" package has a "requires" on
"targetcli-fb-common", as well as "provides" of "targetcli" and
So when a user upgrades from openSUSE 12 to openSUSE 15, the software
knows to replace "targetcli" or "targetcli-fb" with the newer
"python3-targetcli-fb" and it's subpackage "targetcli-fb-common".
The problem occurs when the user had the "targetcli.service" systemd
service enabled in openSUSE 12 and they upgrade to 15. Ownership of the
service file changes from "targetcli-fb" to "python-common-fb", and the
install software (using zypper, I assume) fails to understand that the
service that was under "targetcli-fb" didn't go away, it just changed
ownership to "targetcli-fb-common", and should continue to be enabled.
Is there any way to fix this? If not in this case, what should I do in
the future to avoid this trap?
Thank you for any wisdom you can share!