[opensuse-packaging] renaming service files and keeping enabled state?
Hi, Is there a systemd way to migrate service files and keep enabled state? E.g. We are planning a hawk -> hawk2 migration and would like to transfer the hawk enabled state to hawk2. (Or use something like systemctl status hawk.service || systemctl enable hawk2.service or so) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 17 Aug 2016 12:09, Marcus Meissner wrote:
Hi,
Is there a systemd way to migrate service files and keep enabled state?
E.g. We are planning a hawk -> hawk2 migration and would like to transfer the hawk enabled state to hawk2.
(Or use something like systemctl status hawk.service || systemctl enable hawk2.service or so)
The following works, but is not ideal: in spec-file, before uninstaling hawk, after installing hawk2: systemctl is-enabled hawk.service && systemctl enable hawk2.service be aware of "--root=PATH", it may be needed - Yamaban -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Yamaban <foerster@lisas.de> writes:
On Wed, 17 Aug 2016 12:09, Marcus Meissner wrote:
Hi,
Is there a systemd way to migrate service files and keep enabled state?
E.g. We are planning a hawk -> hawk2 migration and would like to transfer the hawk enabled state to hawk2.
(Or use something like systemctl status hawk.service || systemctl enable hawk2.service or so)
The following works, but is not ideal:
in spec-file, before uninstaling hawk, after installing hawk2:
systemctl is-enabled hawk.service && systemctl enable hawk2.service
be aware of "--root=PATH", it may be needed
The description of the problem is not quite right: We've dropped the hawk package in favor of the hawk2 package (they were co-existing at the same time for a while, but hawk 1 is outdated now). They both provide the hawk systemd service. So a user upgrading will get moved to the hawk2 package, but if the hawk service was enabled before the upgrade, it is now disabled. Cheers, Kristoffer
- Yamaban -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- // Kristoffer Grönlund // kgronlund@suse.com
On Wed, Aug 17, 2016 at 1:35 PM, Kristoffer Grönlund <kgronlund@suse.com> wrote:
The description of the problem is not quite right: We've dropped the hawk package in favor of the hawk2 package (they were co-existing at the same time for a while, but hawk 1 is outdated now). They both provide the hawk systemd service.
So a user upgrading will get moved to the hawk2 package, but if the hawk service was enabled before the upgrade, it is now disabled.
My best guess that this is done by *old* package which is now uninstalled, so it removes and disables services. pre|postun of removed package are executed after pre|post of new package. If this is true, you may try to define triggerpostun in on hawk in hawk2 - this /should/ be executed as last. %pre on hawk2 would then gather current service status and %triggerpostun on hawk in hawk2 would restore it. For reference, execution order for package update is new-%pre for new version of package being installed ... (all new files are installed) new-%post for new version of package being installed any-%triggerin (%triggerin from other packages set off by new install) new-%triggerin old-%triggerun any-%triggerun (%triggerun from other packages set off by old uninstall) old-%preun for old version of package being removed ... (all old files are removed) old-%postun for old version of package being removed old-%triggerpostun any-%triggerpostun (%triggerpostun from other packages set off by old un install) This is not really pure update (we have different packages, still one obsoletes another). Of course this will work only if both are installed/removed in the same transaction. If zypper splits package install and remove between different transactions (and I have strong suspicion it does), all bets are off. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Andrei Borzenkov <arvidjaar@gmail.com> writes:
My best guess that this is done by *old* package which is now uninstalled, so it removes and disables services. pre|postun of removed package are executed after pre|post of new package. If this is true, you may try to define triggerpostun in on hawk in hawk2 - this /should/ be executed as last. %pre on hawk2 would then gather current service status and %triggerpostun on hawk in hawk2 would restore it.
Aah... yes, it's probably this, in the old package: %preun %service_del_preun hawk.service %postun %service_del_postun hawk.service I'll see if I can make sense of triggerpostun, and if it works. -- // Kristoffer Grönlund // kgronlund@suse.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Andrei Borzenkov <arvidjaar@gmail.com> writes:
On Wed, Aug 17, 2016 at 1:35 PM, Kristoffer Grönlund <kgronlund@suse.com> wrote:
The description of the problem is not quite right: We've dropped the hawk package in favor of the hawk2 package (they were co-existing at the same time for a while, but hawk 1 is outdated now). They both provide the hawk systemd service.
So a user upgrading will get moved to the hawk2 package, but if the hawk service was enabled before the upgrade, it is now disabled.
My best guess that this is done by *old* package which is now uninstalled, so it removes and disables services. pre|postun of removed package are executed after pre|post of new package. If this is true, you may try to define triggerpostun in on hawk in hawk2 - this /should/ be executed as last. %pre on hawk2 would then gather current service status and %triggerpostun on hawk in hawk2 would restore it.
Hi Andrei, Thank you for your help, enabling the hawk service in %triggerpostun does seem to run correctly, at least in my initial simple test. However, I haven't managed to implement the second part: Gathering the current status in %pre and only enabling it if it was enabled before. I've been digging through the RPM book and the net to find an example of how to keep state between scriptlets, but haven't figured it out. I tried writing a temporary file to %_tmppath, but then the rpmlint checks failed complaining about non-idempotent scriptlets. Do you have an example of how to do this? Cheers, Kristoffer -- // Kristoffer Grönlund // kgronlund@suse.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
19.08.2016 09:43, Kristoffer Grönlund пишет:
Andrei Borzenkov <arvidjaar@gmail.com> writes:
On Wed, Aug 17, 2016 at 1:35 PM, Kristoffer Grönlund <kgronlund@suse.com> wrote:
The description of the problem is not quite right: We've dropped the hawk package in favor of the hawk2 package (they were co-existing at the same time for a while, but hawk 1 is outdated now). They both provide the hawk systemd service.
So a user upgrading will get moved to the hawk2 package, but if the hawk service was enabled before the upgrade, it is now disabled.
My best guess that this is done by *old* package which is now uninstalled, so it removes and disables services. pre|postun of removed package are executed after pre|post of new package. If this is true, you may try to define triggerpostun in on hawk in hawk2 - this /should/ be executed as last. %pre on hawk2 would then gather current service status and %triggerpostun on hawk in hawk2 would restore it.
Hi Andrei,
Thank you for your help, enabling the hawk service in %triggerpostun does seem to run correctly, at least in my initial simple test.
However, I haven't managed to implement the second part: Gathering the current status in %pre and only enabling it if it was enabled before. I've been digging through the RPM book and the net to find an example of how to keep state between scriptlets, but haven't figured it out. I tried writing a temporary file to %_tmppath, but then the rpmlint checks failed complaining about non-idempotent scriptlets.
That's probably not rpmlint but OBS; I do not know much what runs when package is built or where to find sources for it.
Do you have an example of how to do this?
The only possibility is via some external file and actually that is what systemd macros do at the end. May ne ask on obs list what this error means and how to work around it? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Andrei Borzenkov <arvidjaar@gmail.com> writes:
19.08.2016 09:43, Kristoffer Grönlund пишет: That's probably not rpmlint but OBS; I do not know much what runs when package is built or where to find sources for it.
Do you have an example of how to do this?
The only possibility is via some external file and actually that is what systemd macros do at the end. May ne ask on obs list what this error means and how to work around it?
Ah, I'll take a look at the systemd macros and see if there is anything special going on there. Will ask on the obs list if I can't work it out. Thank you for all the help! Cheers, Kristoffer -- // Kristoffer Grönlund // kgronlund@suse.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 17 Aug 2016 12:35, Kristoffer Grönlund wrote:
Yamaban writes:
On Wed, 17 Aug 2016 12:09, Marcus Meissner wrote:
Hi,
Is there a systemd way to migrate service files and keep enabled state?
E.g. We are planning a hawk -> hawk2 migration and would like to transfer the hawk enabled state to hawk2.
(Or use something like systemctl status hawk.service || systemctl enable hawk2.service or so)
The following works, but is not ideal:
in spec-file, before uninstaling hawk, after installing hawk2:
systemctl is-enabled hawk.service && systemctl enable hawk2.service
be aware of "--root=PATH", it may be needed
The description of the problem is not quite right: We've dropped the hawk package in favor of the hawk2 package (they were co-existing at the same time for a while, but hawk 1 is outdated now). They both provide the hawk systemd service.
So a user upgrading will get moved to the hawk2 package, but if the hawk service was enabled before the upgrade, it is now disabled.
Eh? hawk1 provides hawk.service, by your words hawk2 ALSO provides hawk.service (so the enable/mask sym-links are kept, no fuss at all) IF you REALLY want a coexistence go the way of the displaymanager.service hawk1 shall provide hawk1.service, hawk2 shall provide hawk2.service, "hawk" meta package provides hawk.service to switch between hawk1 and hawk2 Or go the way of a message similar to "Adobe-Flash Liciense" with the info for the user to do the re-eablement themselfs. - Yamaban
Yamaban <foerster@lisas.de> writes:
hawk1 provides hawk.service, by your words hawk2 ALSO provides hawk.service (so the enable/mask sym-links are kept, no fuss at all)
That would be great, but it doesn't seem to be the case. The enable sym-link disappears: krig@e250:~> sudo systemctl status hawk ● hawk.service - HA Web Konsole Loaded: loaded (/usr/lib/systemd/system/hawk.service; enabled; vendor preset: disabled) Active: inactive (dead) krig@e250:~> sudo zypper in hawk2 Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: hawk2 The following package is going to be REMOVED: hawk [...snip...] (1/1) Installing: hawk2-2.0.0+git.1468428505.0135e38-66.1 ...............................................................................................................................[done] There are some running programs that might use files deleted by recent upgrade. You may wish to check and restart some of them. Run 'zypper ps' to list these programs. krig@e250:~> sudo systemctl status hawk ● hawk.service - HA Web Konsole Loaded: loaded (/usr/lib/systemd/system/hawk.service; disabled; vendor preset: disabled) Active: inactive (dead) -- // Kristoffer Grönlund // kgronlund@suse.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Kristoffer Grönlund -
Marcus Meissner -
Yamaban