A python packaging single spec issue when upgrading a package
Hi All: I have a question about python single-spec packaging. [tl;dr: systemd targetcli service goes from enabled to disabled during upgrade.] [BACKGROUND] ------------ Quite a while ago I had to upgrade the "targetcli-fb" package in SLES and openSUSE. 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 "targetcli-fb". 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] ------------- 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! -- Lee Duncan
Hi, Am 02.07.21 um 17:12 schrieb Lee Duncan:
I would say this has nothing to do with python singlespec except for the fact that it is the reason for the package split. Two things to consider: - The systemd packaging guidelines [1] talk about enabling units and installation order. You could try to experiment with the different scriptlets considering their ordering [2, 3] in order not to uninstall the old units before the new units get installed. - Did you try a `Provides: targetcli-fb:...targetcli.service` split-alias [4] for targetcli-fb-common? The wiki talks about YaST. I have no idea, if it also is valid for zypper and if it adds anything to the already present `Requires: targetcli-fb-common` in python3-targetcli-fb. [1] https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines [2] https://rpm-packaging-guide.github.io/#triggers-and-scriptlets [3] https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets#Scriptlet_Orde... [4] https://en.opensuse.org/openSUSE:Package_dependencies#Splitting_a_package_in... HTH, Ben
Hi, Am 02.07.21 um 17:12 schrieb Lee Duncan:
I would say this has nothing to do with python singlespec except for the fact that it is the reason for the package split. Two things to consider: - The systemd packaging guidelines [1] talk about enabling units and installation order. You could try to experiment with the different scriptlets considering their ordering [2, 3] in order not to uninstall the old units before the new units get installed. - Did you try a `Provides: targetcli-fb:...targetcli.service` split-alias [4] for targetcli-fb-common? The wiki talks about YaST. I have no idea, if it also is valid for zypper and if it adds anything to the already present `Requires: targetcli-fb-common` in python3-targetcli-fb. [1] https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines [2] https://rpm-packaging-guide.github.io/#triggers-and-scriptlets [3] https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets#Scriptlet_Orde... [4] https://en.opensuse.org/openSUSE:Package_dependencies#Splitting_a_package_in... HTH, Ben
participants (2)
-
Ben Greiner -
Lee Duncan