[opensuse-factory] RPM %pre and %post parameters when obsoleting a package
Hello! I'm currently trying to solve a tricky problem with the google-compute-engine-{init,oslogin} and google-guest-{agent,oslogin,configs} packages. The latter are replacement packages for the former, i.e. the google-guest-* packages are obsoleting the google-compute-engine-* packages. The google-guest-* packages contain systemd services which need to be enabled in case the packages are being installed as an upgrade over the old google-compute-engine-* packages. While RPM has a mechanism for determining whether a package is being upgraded or newly installed [1], this mechanism does not work when the upgrade process involves replacing the old packages with a new package involving the Obsoletes+Replaces mechanism. The reason why that doesn't work is because the scriptlet parameter that indicates the upgrade process actually just notifies the scriptlet of the number of packages with the same name are currently being installed which is "2" during an upgrade [1], so that number will be "1" when google-compute-engine-oslogin is being replaced with google-guest-oslogin, for example. Does anyone have a suggestion how to solve this? I have been thinking about writing a temporary file empty to the filesystem in the %pre scriptlet to disk which is then detected by the %post scriptlet. The empty file would be written if the old services are found as enabled in the %pre section and the %post section would enable the services if the temporary file is found. The file can be created with "mktemp --suffix .google-compute-engine". Any other suggestions? Adrian
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_synta... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
21.08.2020 14:50, John Paul Adrian Glaubitz пишет:
Hello!
I'm currently trying to solve a tricky problem with the google-compute-engine-{init,oslogin} and google-guest-{agent,oslogin,configs} packages. The latter are replacement packages for the former, i.e. the google-guest-* packages are obsoleting the google-compute-engine-* packages.
The google-guest-* packages contain systemd services which need to be enabled in case the packages are being installed as an upgrade over the old google-compute-engine-* packages.
While RPM has a mechanism for determining whether a package is being upgraded or newly installed [1], this mechanism does not work when the upgrade process involves replacing the old packages with a new package involving the Obsoletes+Replaces mechanism.
The reason why that doesn't work is because the scriptlet parameter that indicates the upgrade process actually just notifies the scriptlet of the number of packages with the same name are currently being installed which is "2" during an upgrade [1], so that number will be "1" when google-compute-engine-oslogin is being replaced with google-guest-oslogin, for example.
Does anyone have a suggestion how to solve this? I have been thinking about writing a temporary file empty to the filesystem in the %pre scriptlet to disk which is then detected by the %post scriptlet.
The empty file would be written if the old services are found as enabled in the %pre section and the %post section would enable the services if the temporary file is found. The file can be created with "mktemp --suffix .google-compute-engine".
Any other suggestions?
It may work with triggers. Add %triggerun -- google-compute-engine-oslogin if [ "$2" -eq 0 ]; then do your conversion fi to google-guest-oslogin package (I do not know exact package structure so pick your choice). Trigger will run when google-compute-engine-oslogin before any package scripts and before package is deleted, so will see current package state. Triggers get number of remaining target packages as $2 (similar to $1 for regular scripts). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov <arvidjaar@gmail.com> writes:
21.08.2020 14:50, John Paul Adrian Glaubitz пишет:
Hello!
I'm currently trying to solve a tricky problem with the google-compute-engine-{init,oslogin} and google-guest-{agent,oslogin,configs} packages. The latter are replacement packages for the former, i.e. the google-guest-* packages are obsoleting the google-compute-engine-* packages.
The google-guest-* packages contain systemd services which need to be enabled in case the packages are being installed as an upgrade over the old google-compute-engine-* packages.
While RPM has a mechanism for determining whether a package is being upgraded or newly installed [1], this mechanism does not work when the upgrade process involves replacing the old packages with a new package involving the Obsoletes+Replaces mechanism.
The reason why that doesn't work is because the scriptlet parameter that indicates the upgrade process actually just notifies the scriptlet of the number of packages with the same name are currently being installed which is "2" during an upgrade [1], so that number will be "1" when google-compute-engine-oslogin is being replaced with google-guest-oslogin, for example.
Does anyone have a suggestion how to solve this? I have been thinking about writing a temporary file empty to the filesystem in the %pre scriptlet to disk which is then detected by the %post scriptlet.
The empty file would be written if the old services are found as enabled in the %pre section and the %post section would enable the services if the temporary file is found. The file can be created with "mktemp --suffix .google-compute-engine".
Any other suggestions?
It may work with triggers. Add
%triggerun -- google-compute-engine-oslogin
Note that you have to use file triggers (%filetrigger[in|un]) and don't use %transfiletrigger[in|un] as these are unreliable in zypper [1]. Cheers, Dan Footnotes: [1] https://bugzilla.suse.com/show_bug.cgi?id=1041742 -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
22.08.2020 09:13, Dan Čermák пишет:
Andrei Borzenkov <arvidjaar@gmail.com> writes:
21.08.2020 14:50, John Paul Adrian Glaubitz пишет:
Hello!
I'm currently trying to solve a tricky problem with the google-compute-engine-{init,oslogin} and google-guest-{agent,oslogin,configs} packages. The latter are replacement packages for the former, i.e. the google-guest-* packages are obsoleting the google-compute-engine-* packages.
The google-guest-* packages contain systemd services which need to be enabled in case the packages are being installed as an upgrade over the old google-compute-engine-* packages.
While RPM has a mechanism for determining whether a package is being upgraded or newly installed [1], this mechanism does not work when the upgrade process involves replacing the old packages with a new package involving the Obsoletes+Replaces mechanism.
The reason why that doesn't work is because the scriptlet parameter that indicates the upgrade process actually just notifies the scriptlet of the number of packages with the same name are currently being installed which is "2" during an upgrade [1], so that number will be "1" when google-compute-engine-oslogin is being replaced with google-guest-oslogin, for example.
Does anyone have a suggestion how to solve this? I have been thinking about writing a temporary file empty to the filesystem in the %pre scriptlet to disk which is then detected by the %post scriptlet.
The empty file would be written if the old services are found as enabled in the %pre section and the %post section would enable the services if the temporary file is found. The file can be created with "mktemp --suffix .google-compute-engine".
Any other suggestions?
It may work with triggers. Add
%triggerun -- google-compute-engine-oslogin
Note that you have to use file triggers (%filetrigger[in|un]) and don't
Why "have to"? You /may/ use filetriggers, but plain old triggers should work as well. Normal triggers are at least documented (to the extent) while filetriggers remain complete mystery so far.
use %transfiletrigger[in|un] as these are unreliable in zypper [1].
Cheers,
Dan
Footnotes: [1] https://bugzilla.suse.com/show_bug.cgi?id=1041742
Andrei Borzenkov <arvidjaar@gmail.com> writes:
Why "have to"? You /may/ use filetriggers, but plain old triggers should work as well. Normal triggers are at least documented (to the extent) while filetriggers remain complete mystery so far.
Apologies, I must confess that I only read quickly through your email before leaving my PC in the morning and did not read it well enough, as I thought you were talking about file triggers (FYI: https://rpm.org/user_doc/file_triggers.html) Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On 8/21/20 9:20 PM, John Paul Adrian Glaubitz wrote:
Hello!
I'm currently trying to solve a tricky problem with the google-compute-engine-{init,oslogin} and google-guest-{agent,oslogin,configs} packages. The latter are replacement packages for the former, i.e. the google-guest-* packages are obsoleting the google-compute-engine-* packages.
The google-guest-* packages contain systemd services which need to be enabled in case the packages are being installed as an upgrade over the old google-compute-engine-* packages.
While RPM has a mechanism for determining whether a package is being upgraded or newly installed [1], this mechanism does not work when the upgrade process involves replacing the old packages with a new package involving the Obsoletes+Replaces mechanism.
The reason why that doesn't work is because the scriptlet parameter that indicates the upgrade process actually just notifies the scriptlet of the number of packages with the same name are currently being installed which is "2" during an upgrade [1], so that number will be "1" when google-compute-engine-oslogin is being replaced with google-guest-oslogin, for example.
Does anyone have a suggestion how to solve this? I have been thinking about writing a temporary file empty to the filesystem in the %pre scriptlet to disk which is then detected by the %post scriptlet.
The empty file would be written if the old services are found as enabled in the %pre section and the %post section would enable the services if the temporary file is found. The file can be created with "mktemp --suffix .google-compute-engine".
Any other suggestions?
Not really an other suggestion, but for a while docker used to check the version of docker in %pre then based off that write a file to disk indicating that a special migration action needed to take place in %postun https://build.opensuse.org/package/view_file/openSUSE:Leap:42.1:Update/docke... -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
John Paul Adrian Glaubitz wrote:
[...] The empty file would be written if the old services are found as enabled in the %pre section and the %post section would enable the services if the temporary file is found. The file can be created with "mktemp --suffix .google-compute-engine".
Carrying over the enabled state of a service on package or service rename seems to be recurring problem. Could we maybe extend the service handling to detect that situation automatically? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/25/20 9:35 AM, Ludwig Nussel wrote:
Carrying over the enabled state of a service on package or service rename seems to be recurring problem. Could we maybe extend the service handling to detect that situation automatically?
Oh yeah, that would actually be very useful. I think the fact that the %preun and %postun scriptlets of the old package are executed after the %post scriptlets of the new package makes it so complicated. If the %service_{add,del}_{pre,post}{,un} scriptlets would do that automatically, it would help simplify the process quite a bit. Thanks, Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Andrei Borzenkov -
Dan Čermák -
John Paul Adrian Glaubitz -
Ludwig Nussel -
Simon Lees