[opensuse-packaging] Checking whether package is being upgraded
Hi! What is the easiest way to determine during the %post scriptlet in a spec file whether the package is currently being upgraded instead of being installed? I checked the documentation but couldn't find anything relevant. I also tried testing whether the first argument to rpm is "2", i.e. "$1 -eq 2" similar to [1] but that seems to work on Fedora only. Anyone can give me a quick hint? Thanks, Adrian
[1] https://github.com/GoogleCloudPlatform/compute-image-packages/blob/master/sp... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Jun 18, John Paul Adrian Glaubitz wrote:
Hi!
What is the easiest way to determine during the %post scriptlet in a spec file whether the package is currently being upgraded instead of being installed?
I checked the documentation but couldn't find anything relevant. I also tried testing whether the first argument to rpm is "2", i.e. "$1 -eq 2" similar to [1] but that seems to work on Fedora only.
Anyone can give me a quick hint?
This works: http://meinit.nl/rpm-spec-prepostpreunpostun-argument-values Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/18/2018 01:03 PM, Thorsten Kukuk wrote:
Anyone can give me a quick hint?
This works: http://meinit.nl/rpm-spec-prepostpreunpostun-argument-values
Ok, so my current script code is correct. But I just noticed I made a different mistake. Thanks for confirming this, Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/18/2018 01:50 PM, John Paul Adrian Glaubitz wrote:
On 06/18/2018 01:03 PM, Thorsten Kukuk wrote:
Anyone can give me a quick hint?
This works: http://meinit.nl/rpm-spec-prepostpreunpostun-argument-values
Ok, so my current script code is correct. But I just noticed I made a different mistake.
Is this also supposed to work with the RPM version found in SLE-11-SP4? My tests show that "$1" is unset on SLE-11-SP4. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/18/2018 03:33 PM, John Paul Adrian Glaubitz wrote:
On 06/18/2018 01:50 PM, John Paul Adrian Glaubitz wrote:
On 06/18/2018 01:03 PM, Thorsten Kukuk wrote:
Anyone can give me a quick hint?
This works: http://meinit.nl/rpm-spec-prepostpreunpostun-argument-values
Ok, so my current script code is correct. But I just noticed I made a different mistake.
Is this also supposed to work with the RPM version found in SLE-11-SP4? My tests show that "$1" is unset on SLE-11-SP4.
Ah, the %fillup_and_insserv macros seems to invoke "shift" which clears the variable... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/18/2018 09:33 AM, John Paul Adrian Glaubitz wrote:
On 06/18/2018 01:50 PM, John Paul Adrian Glaubitz wrote:
On 06/18/2018 01:03 PM, Thorsten Kukuk wrote:
Anyone can give me a quick hint?
This works: http://meinit.nl/rpm-spec-prepostpreunpostun-argument-values
Ok, so my current script code is correct. But I just noticed I made a different mistake.
Is this also supposed to work with the RPM version found in SLE-11-SP4? My tests show that "$1" is unset on SLE-11-SP4.
I do not know to this question, however since I know what you are after and given SLES 11 has only 9 months to EOL I'll offer a diferent approach to skin the cat. You can test if the init file of the service to be replaced exists, if yes (package upgrade) do the "replacement magic". If not fresh install, => nothing to do. HTH, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo
On 06/18/2018 04:10 PM, Robert Schweikert wrote:
Is this also supposed to work with the RPM version found in SLE-11-SP4? My tests show that "$1" is unset on SLE-11-SP4.
I do not know to this question, however since I know what you are after and given SLES 11 has only 9 months to EOL I'll offer a diferent approach to skin the cat.
You can test if the init file of the service to be replaced exists, if yes (package upgrade) do the "replacement magic". If not fresh install, => nothing to do.
The current spec file actually does already the right thing: It deletes the old init scripts and installs the new one. What I cannot figure out is how to start the new google-network-daemon after installing the package. The problem is that during the build process, rpmbuild apparentely tries to install the package which then invokes the script code to start the google- network-daemon service: [ 146s] Preparing packages for installation... [ 146s] google-compute-engine-debuginfo-20180510-0 [ 146s] google-compute-engine-oslogin-20180510-0 [ 146s] google-compute-engine-debugsource-20180510-0 [ 146s] google-compute-engine-init-20180510-0 [ 147s] ... running 01-check-debuginfo [ 147s] ... testing for empty debuginfo packages [ 147s] ! [ 147s] ! google-compute-engine-debugsource-20180510-0.x86_64.rpm: no debug sources, deleting package [ 147s] ! google-compute-engine-debuginfo-20180510-0.x86_64.rpm: WARNING: this probably means the debug information is invalid [ 147s] ! [ 147s] ... running 02-check-gcc-output [ 147s] ... testing for serious compiler warnings [ 147s] (using /usr/lib/build/checks-data/check_gcc_output) [ 147s] (using /var/tmp/build-root/standard-x86_64/.build.log) [ 147s] ... running 03-check-binary-kernel-log [ 147s] ... running 04-check-filelist [ 147s] ... checking filelist [ 147s] ... running 05-check-invalid-requires [ 147s] dependency check for google-compute-engine-debuginfo-20180510-0.x86_64.rpm: [ 147s] ... running 06-check-installtest [ 147s] ... testing for pre/postinstall scripts that are not idempotent [ 147s] Starting google-network-daemon daemon Traceback (most recent call last): [ 147s] File "/usr/bin/google_network_daemon", line 8, in <module> [ 147s] load_entry_point('google-compute-engine==2.8.2', 'console_scripts', 'google_network_daemon')() [ 147s] File "/usr/lib64/python2.6/site-packages/google_compute_engine/networking/network_daemon.py", line 172, in main [ 147s] debug=debug) [ 147s] File "/usr/lib64/python2.6/site-packages/google_compute_engine/networking/network_daemon.py", line 60, in __init__ [ 147s] name='google-networking', debug=debug, facility=facility) [ 147s] File "/usr/lib64/python2.6/site-packages/google_compute_engine/logger.py", line 49, in Logger [ 147s] address='/dev/log', facility=facility) [ 147s] File "/usr/lib64/python2.6/logging/handlers.py", line 715, in __init__ [ 147s] self._connect_unixsocket(address) [ 147s] File "/usr/lib64/python2.6/logging/handlers.py", line 730, in _connect_unixsocket [ 147s] self.socket.connect(address) [ 147s] File "<string>", line 1, in connect [ 147s] socket.error: [Errno 2] No such file or directory [ 147s] ..failed [ 147s] postinstall script of google-compute-engine-init-20180510-0.x86_64.rpm failed -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Jun 18, John Paul Adrian Glaubitz wrote:
The current spec file actually does already the right thing: It deletes the old init scripts and installs the new one. What I cannot figure out is how to start the new google-network-daemon after installing the package.
You mean from the RPM? NEVER EVER do that! Neither at a fresh installation nor during upgrade. This will break a lot of stuff. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/18/2018 04:26 PM, Thorsten Kukuk wrote:
On Mon, Jun 18, John Paul Adrian Glaubitz wrote:
The current spec file actually does already the right thing: It deletes the old init scripts and installs the new one. What I cannot figure out is how to start the new google-network-daemon after installing the package.
You mean from the RPM? NEVER EVER do that! Neither at a fresh installation nor during upgrade. This will break a lot of stuff.
I have explicitly been asked to do that in bsc#1092214. How do I make sure then a mandatory service gets started once I install a package? The problem we have is that the package upgrade replaces two old services with a unified service, so the old services need to be stopped and the new one needs to be started. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/18/2018 10:18 AM, John Paul Adrian Glaubitz wrote:
On 06/18/2018 04:10 PM, Robert Schweikert wrote:
Is this also supposed to work with the RPM version found in SLE-11-SP4? My tests show that "$1" is unset on SLE-11-SP4.
I do not know to this question, however since I know what you are after and given SLES 11 has only 9 months to EOL I'll offer a diferent approach to skin the cat.
You can test if the init file of the service to be replaced exists, if yes (package upgrade) do the "replacement magic". If not fresh install, => nothing to do.
The current spec file actually does already the right thing: It deletes the old init scripts and installs the new one. What I cannot figure out is how to start the new google-network-daemon after installing the package.
The problem is that during the build process, rpmbuild apparentely tries to install the package which then invokes the script code to start the google- network-daemon service:
[ 146s] Preparing packages for installation... [ 146s] google-compute-engine-debuginfo-20180510-0 [ 146s] google-compute-engine-oslogin-20180510-0 [ 146s] google-compute-engine-debugsource-20180510-0 [ 146s] google-compute-engine-init-20180510-0 [ 147s] ... running 01-check-debuginfo [ 147s] ... testing for empty debuginfo packages [ 147s] ! [ 147s] ! google-compute-engine-debugsource-20180510-0.x86_64.rpm: no debug sources, deleting package [ 147s] ! google-compute-engine-debuginfo-20180510-0.x86_64.rpm: WARNING: this probably means the debug information is invalid [ 147s] ! [ 147s] ... running 02-check-gcc-output [ 147s] ... testing for serious compiler warnings [ 147s] (using /usr/lib/build/checks-data/check_gcc_output) [ 147s] (using /var/tmp/build-root/standard-x86_64/.build.log) [ 147s] ... running 03-check-binary-kernel-log [ 147s] ... running 04-check-filelist [ 147s] ... checking filelist [ 147s] ... running 05-check-invalid-requires [ 147s] dependency check for google-compute-engine-debuginfo-20180510-0.x86_64.rpm: [ 147s] ... running 06-check-installtest [ 147s] ... testing for pre/postinstall scripts that are not idempotent [ 147s] Starting google-network-daemon daemon Traceback (most recent call last): [ 147s] File "/usr/bin/google_network_daemon", line 8, in <module> [ 147s] load_entry_point('google-compute-engine==2.8.2', 'console_scripts', 'google_network_daemon')() [ 147s] File "/usr/lib64/python2.6/site-packages/google_compute_engine/networking/network_daemon.py", line 172, in main [ 147s] debug=debug) [ 147s] File "/usr/lib64/python2.6/site-packages/google_compute_engine/networking/network_daemon.py", line 60, in __init__ [ 147s] name='google-networking', debug=debug, facility=facility) [ 147s] File "/usr/lib64/python2.6/site-packages/google_compute_engine/logger.py", line 49, in Logger [ 147s] address='/dev/log', facility=facility) [ 147s] File "/usr/lib64/python2.6/logging/handlers.py", line 715, in __init__ [ 147s] self._connect_unixsocket(address) [ 147s] File "/usr/lib64/python2.6/logging/handlers.py", line 730, in _connect_unixsocket [ 147s] self.socket.connect(address) [ 147s] File "<string>", line 1, in connect [ 147s] socket.error: [Errno 2] No such file or directory [ 147s] ..failed [ 147s] postinstall script of google-compute-engine-init-20180510-0.x86_64.rpm failed
There is something wrong with the logic. OBS does an install test, not an "upgrade", so the services that get replaced are not running and thus the new service should not be started. The service should only be started and enabled on package upgrade. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo
On 06/18/2018 05:22 PM, Robert Schweikert wrote:
There is something wrong with the logic. OBS does an install test, not an "upgrade", so the services that get replaced are not running and thus the new service should not be started. The service should only be started and enabled on package upgrade.
I thought that as well, but according to the documentation, "$1" is equal to "2" for upgrades and that's what I am testing: if [ "$1" == "2" ]; then service google-network-daemon start fi This fails during build. However, when I add testing for "/.buildenv" as suggested by Marcus, it works: if [ "$1" == "2" ] && ! [ -e /.buildenv ]; then service google-network-daemon start fi Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/18/2018 05:30 PM, John Paul Adrian Glaubitz wrote:
I thought that as well, but according to the documentation, "$1" is equal to "2" for upgrades and that's what I am testing:
if [ "$1" == "2" ]; then service google-network-daemon start fi
This fails during build.
However, when I add testing for "/.buildenv" as suggested by Marcus, it works:
if [ "$1" == "2" ] && ! [ -e /.buildenv ]; then service google-network-daemon start fi
I have just verified that this change does the right thing on SLE-11-SP4 and SLE-12-SP3: Index: google-compute-engine.changes =================================================================== --- google-compute-engine.changes (revision 4c54794cf9a7b720f0f1091d2a152b0e) +++ google-compute-engine.changes (working copy) @@ -1,3 +1,12 @@ +------------------------------------------------------------------- +Mon Jun 18 15:53:01 UTC 2018 - adrian.glaubitz@suse.com + +- Ensure that google-ip-forwarding-daemon service and + google-network-setup are actually stopped and disabled + during upgrade +- Ensure that google-network-daemon service is actually + enabled and started during upgrade + ------------------------------------------------------------------- Thu Jun 14 10:31:14 UTC 2018 - adrian.glaubitz@suse.com Index: google-compute-engine.spec =================================================================== --- google-compute-engine.spec (revision 4c54794cf9a7b720f0f1091d2a152b0e) +++ google-compute-engine.spec (working copy) @@ -169,7 +169,23 @@ %post init %if 0%{?suse_version} > 1140 %service_add_post google-accounts-daemon.service google-clock-skew-daemon.service google-instance-setup.service google-network-daemon.service google-shutdown-scripts.service google-startup-scripts.service -%else + if [ -f /usr/lib/systemd/system/google-ip-forwarding-daemon.service ]; then + systemctl stop --no-block google-ip-forwarding-daemon + systemctl disable google-ip-forwarding-daemon.service + fi + if [ -f /usr/lib/systemd/system/google-network-setup.service ]; then + systemctl stop --no-block google-network-setup + systemctl disable google-network-setup.service + fi + if [ "$1" == "2" ] && ! [ -e /.buildenv ]; then + systemctl enable google-network-daemon.service + systemctl start google-network-daemon.service + fi +%else + if [ "$1" == "2" ] && ! [ -e /.buildenv ]; then + service google-network-daemon start + fi + %fillup_and_insserv -fy google-accounts-daemon %fillup_and_insserv -fy google-clock-skew-daemon %fillup_and_insserv -fy google-instance-setup Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Mon, 18 Jun 2018, John Paul Adrian Glaubitz wrote:
+ if [ -f /usr/lib/systemd/system/google-ip-forwarding-daemon.service ]; then + systemctl stop --no-block google-ip-forwarding-daemon + systemctl disable google-ip-forwarding-daemon.service + fi + if [ -f /usr/lib/systemd/system/google-network-setup.service ]; then + systemctl stop --no-block google-network-setup + systemctl disable google-network-setup.service + fi + if [ "$1" == "2" ] && ! [ -e /.buildenv ]; then + systemctl enable google-network-daemon.service + systemctl start google-network-daemon.service + fi +%else + if [ "$1" == "2" ] && ! [ -e /.buildenv ]; then + service google-network-daemon start + fi
I think if anything you should only enable/start the new service if both the old services were enabled and started already. Think of a user who has the package installed, but disabled the services as conscious decision. After upgrade he suddenly has the service enabled again. Generally we have the policy of not starting or enabling services when installing packages, except for Very Good Reasons (and somebody requesting it somewhere is not necessarily one). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi Michael! On 06/18/2018 07:40 PM, Michael Matz wrote:
I think if anything you should only enable/start the new service if both the old services were enabled and started already. Think of a user who has the package installed, but disabled the services as conscious decision. After upgrade he suddenly has the service enabled again. Generally we have the policy of not starting or enabling services when installing packages, except for Very Good Reasons (and somebody requesting it somewhere is not necessarily one).
In generally I would agree with your stance. However, google-compute-engine is a package for a very specific purpose, namely the instance initialization and management in Google's GCE cloud. It's not designed to be used outside GCE and is also not of any use there. And in the GCE cloud, the services are necessary to be running such that the instance can be properly initialized. Otherwise it could happen that a user won't be able to login after starting the instance. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19/06/18 06:16, John Paul Adrian Glaubitz wrote:
Hi Michael!
On 06/18/2018 07:40 PM, Michael Matz wrote:
I think if anything you should only enable/start the new service if both the old services were enabled and started already. Think of a user who has the package installed, but disabled the services as conscious decision. After upgrade he suddenly has the service enabled again. Generally we have the policy of not starting or enabling services when installing packages, except for Very Good Reasons (and somebody requesting it somewhere is not necessarily one).
In generally I would agree with your stance. However, google-compute-engine is a package for a very specific purpose, namely the instance initialization and management in Google's GCE cloud.
It's not designed to be used outside GCE and is also not of any use there. And in the GCE cloud, the services are necessary to be running such that the instance can be properly initialized. Otherwise it could happen that a user won't be able to login after starting the instance.
Adrian
It doesn't matter how "special / specific" the package is packages enabling or starting there own services when they are not enabled are against openSUSE's packaging requirements and will be rejected by the package review team. -- 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
On 19.06.2018 04:51, Simon Lees wrote:
It doesn't matter how "special / specific" the package is packages enabling or starting there own services when they are not enabled are against openSUSE's packaging requirements and will be rejected by the package review team.
Let me translate this: "No matter if the package is absolutely useless or not, the only important thing is that it complies to openSUSE's packaging requirements!!11!!" (Reminds me of the "let's drop systemd-resolved, because we don't want to implement a workaround in the image" decision) If your mission is "let's create a technically totally awesome (no workarounds, no dirty hacks) but absolutely useless Linux distribution", you are totally on the right track. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19/06/18 16:08, Stefan Seyfried wrote:
On 19.06.2018 04:51, Simon Lees wrote:
It doesn't matter how "special / specific" the package is packages enabling or starting there own services when they are not enabled are against openSUSE's packaging requirements and will be rejected by the package review team.
Let me translate this:
"No matter if the package is absolutely useless or not, the only important thing is that it complies to openSUSE's packaging requirements!!11!!"
(Reminds me of the "let's drop systemd-resolved, because we don't want to implement a workaround in the image" decision)
If your mission is "let's create a technically totally awesome (no workarounds, no dirty hacks) but absolutely useless Linux distribution", you are totally on the right track.
Yep I know how much you enjoy our rules, but for the package in question it is simply a matter of checking if the service is running before deciding to start the new services which isn't exactly hard. -- 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
Simon, On 06/19/2018 09:18 AM, Simon Lees wrote:
Yep I know how much you enjoy our rules, but for the package in question it is simply a matter of checking if the service is running before deciding to start the new services which isn't exactly hard.
You are ignoring the fact that it a) does not make sense to not run the service, b) this particular change was requested by an important customer. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/19/2018 09:18 AM, Simon Lees wrote:
Yep I know how much you enjoy our rules, but for the package in question it is simply a matter of checking if the service is running before deciding to start the new services which isn't exactly hard.
Also, this argument is moot as the service in question cannot be running as it doesn't exist in previous versions in the first place. The new service is replacing two old services and it's supposed to be started after the two old services have been stopped and disabled. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19/06/18 17:01, John Paul Adrian Glaubitz wrote:
On 06/19/2018 09:18 AM, Simon Lees wrote:
Yep I know how much you enjoy our rules, but for the package in question it is simply a matter of checking if the service is running before deciding to start the new services which isn't exactly hard.
Also, this argument is moot as the service in question cannot be running as it doesn't exist in previous versions in the first place.
The new service is replacing two old services and it's supposed to be started after the two old services have been stopped and disabled.
Yes but before stopping the old service you can check to see if it was actually running and then use that to determine whether or not you should start the new service (The same for enabling the new services because the systemd macro's won't do that automatically either). -- 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
On 06/19/2018 09:47 AM, Simon Lees wrote:
Yes but before stopping the old service you can check to see if it was actually running and then use that to determine whether or not you should start the new service (The same for enabling the new services because the systemd macro's won't do that automatically either).
As I said before, this particular scenario doesn't exist. The service(s) are required for the cloud instances to be properly initialized and set up in GCE. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19/06/18 17:23, John Paul Adrian Glaubitz wrote:
On 06/19/2018 09:47 AM, Simon Lees wrote:
Yes but before stopping the old service you can check to see if it was actually running and then use that to determine whether or not you should start the new service (The same for enabling the new services because the systemd macro's won't do that automatically either).
As I said before, this particular scenario doesn't exist. The service(s) are required for the cloud instances to be properly initialized and set up in GCE.
Adrian
But if you are submitting this package to tumbleweed (You are asking on an openSUSE list) then it would be possible for any tumbleweed user to have this package installed then decide to disable or have never enabled the service. -- 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
On 06/19/2018 10:03 AM, Simon Lees wrote:
But if you are submitting this package to tumbleweed (You are asking on an openSUSE list) then it would be possible for any tumbleweed user to have this package installed then decide to disable or have never enabled the service.
No Tumbleweed user is going to install a package that is necessary for GCE unless they are running Tumbleweed for GCE. The package is completely useless outside GCE. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello Adrian, On Jun 19 10:21 John Paul Adrian Glaubitz wrote (excerpt):
On 06/19/2018 10:03 AM, Simon Lees wrote:
But if you are submitting this package to tumbleweed (You are asking on an openSUSE list) then it would be possible for any tumbleweed user to have this package installed then decide to disable or have never enabled the service.
No Tumbleweed user is going to install a package that is necessary for GCE unless they are running Tumbleweed for GCE. The package is completely useless outside GCE.
It seems you don't get the crucial point. It does not matter what is reasonable or not, it only matters that openSUSE users can install it. I did not read all the many mails in this thread but I think https://lists.opensuse.org/opensuse-packaging/2017-12/msg00037.html was not yet mentioned. See that mail what the official mechanism is to enable systemd services by default (at least in December 2017, perhaps things are different now). Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/19/2018 11:04 AM, Johannes Meixner wrote:
It seems you don't get the crucial point.
I do get the crucial point. I have been a Debian Developer long enough to know these discussions.
It does not matter what is reasonable or not, it only matters that openSUSE users can install it.
And then what exactly would they want to do with it?
I did not read all the many mails in this thread but I think https://lists.opensuse.org/opensuse-packaging/2017-12/msg00037.html was not yet mentioned.
Quote:
Unfortunately, some packages still enable their services at their own by calling systemctl enable in the %post install section. This will break in the future for fresh installations!
Cloud instances are not being installed. They use preconfigured images, so this particular point does not apply either.
See that mail what the official mechanism is to enable systemd services by default (at least in December 2017, perhaps things are different now).
Yes, again. I understand all this. It does not really change the fact that the whole reasoning does not really make sense for this particular package. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19/06/18 17:51, John Paul Adrian Glaubitz wrote:
On 06/19/2018 10:03 AM, Simon Lees wrote:
But if you are submitting this package to tumbleweed (You are asking on an openSUSE list) then it would be possible for any tumbleweed user to have this package installed then decide to disable or have never enabled the service.
No Tumbleweed user is going to install a package that is necessary for GCE unless they are running Tumbleweed for GCE. The package is completely useless outside GCE.
Adrian
Tumbleweed users will always find ways of surprising you, such as installing everything possible in the repo to gather various statistics, to possibly installing every package with google in its name because its the easiest way to get all the google fonts, just because you don't think installing your package is reasonable doesn't mean that people won't install it anyway. Further to that arguing with us here on this list will have no effect as we don't set the rules here we are just enforcing what is already set, if you think the rules should be changed you can consult the broader openSUSE community on the opensuse-factory mailing list, but i'm pretty sure we have been there and discussed this before. -- 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
On 06/19/2018 11:17 AM, Simon Lees wrote:
Tumbleweed users will always find ways of surprising you, such as installing everything possible in the repo to gather various statistics, to possibly installing every package with google in its name because its the easiest way to get all the google fonts, just because you don't think installing your package is reasonable doesn't mean that people won't install it anyway.
Well, yes. If you want to shoot yourself into the foot, you're free to do so. I don't see why we should do anything possible to prevent people from doing that.
Further to that arguing with us here on this list will have no effect as we don't set the rules here we are just enforcing what is already set, if you think the rules should be changed you can consult the broader openSUSE community on the opensuse-factory mailing list, but i'm pretty sure we have been there and discussed this before.
I'm not arguing. I do what I have been asked to do to get a problem with the cloud distribution resolved. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19/06/18 18:51, John Paul Adrian Glaubitz wrote:
On 06/19/2018 11:17 AM, Simon Lees wrote:
Tumbleweed users will always find ways of surprising you, such as installing everything possible in the repo to gather various statistics, to possibly installing every package with google in its name because its the easiest way to get all the google fonts, just because you don't think installing your package is reasonable doesn't mean that people won't install it anyway.
Well, yes. If you want to shoot yourself into the foot, you're free to do so. I don't see why we should do anything possible to prevent people from doing that.
Further to that arguing with us here on this list will have no effect as we don't set the rules here we are just enforcing what is already set, if you think the rules should be changed you can consult the broader openSUSE community on the opensuse-factory mailing list, but i'm pretty sure we have been there and discussed this before.
I'm not arguing. I do what I have been asked to do to get a problem with the cloud distribution resolved.
Adrian
Yes and above all what you are asked to do is follow the openSUSE guidelines when participating as a part of the openSUSE community, which is what every SUSE employee is doing and is expected to do when contributing there code to factory. -- 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
On 06/19/2018 11:41 AM, Simon Lees wrote:
Yes and above all what you are asked to do is follow the openSUSE guidelines when participating as a part of the openSUSE community, which is what every SUSE employee is doing and is expected to do when contributing there code to factory.
You do realize that there is a conflict here and we have to make a decision which we value higher? The fact that the package works correctly for our enterprise customers in the cloud or the possibility that a random Tumbleweed user is installing the package on their laptop only to realize it does not work at all, whether the service is running or not. Strictly following the policy here does not gain anything but it will make the package for its target audience unusable. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19 June 2018 at 11:50, John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
On 06/19/2018 11:41 AM, Simon Lees wrote:
Yes and above all what you are asked to do is follow the openSUSE guidelines when participating as a part of the openSUSE community, which is what every SUSE employee is doing and is expected to do when contributing there code to factory.
You do realize that there is a conflict here and we have to make a decision which we value higher? The fact that the package works correctly for our enterprise customers in the cloud or the possibility that a random Tumbleweed user is installing the package on their laptop only to realize it does not work at all, whether the service is running or not.
Strictly following the policy here does not gain anything but it will make the package for its target audience unusable.
Adrian
I think you should familiarise yourself with SUSE's "Factory First" policy which is the internal policy from which requirement that the SUSE Packaging Guidelines matches the openSUSE ones It's important that SUSE can maintain their packages in the long term without needing to worry about regular rebasing between their Enterprise distributions and the openSUSE communities offering There's no benefit making out-of-band hacks in the name of pleasing customers just to have all of those customers screwed when things break years in the future because that hack can't be rebased with where openSUSE ends up years from now. SUSE value that highly enough that any deviation from Factory First in SLE requires management buy-in to justify the additional work, manpower and risk, required to maintain a package outside of comforting environment offered by openSUSE hosting the package as part of Tumbleweed I think it would be better in the long term that you find a way to work better in the bounds set, I don't see any real justification for doing things differently or changing any policies here. This whole discussion is starting to read to me as "I don't like it so everything should change". And that's not a good way of working as part of a community. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19/06/18 19:20, John Paul Adrian Glaubitz wrote:
On 06/19/2018 11:41 AM, Simon Lees wrote:
Yes and above all what you are asked to do is follow the openSUSE guidelines when participating as a part of the openSUSE community, which is what every SUSE employee is doing and is expected to do when contributing there code to factory.
You do realize that there is a conflict here and we have to make a decision which we value higher? The fact that the package works correctly for our enterprise customers in the cloud or the possibility that a random Tumbleweed user is installing the package on their laptop only to realize it does not work at all, whether the service is running or not.
Strictly following the policy here does not gain anything but it will make the package for its target audience unusable.
Adrian
I'm not sure how checking if the old service was started / enabled before starting / enabling the new services will cause your package to be unusable by your target audience, you have already stated that they will all have the old service started and enabled. Beyond that I don't see any point in me continuing the discussion here. -- 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
On 06/19/2018 12:17 PM, Simon Lees wrote:
I'm not sure how checking if the old service was started / enabled before starting / enabling the new services will cause your package to be unusable by your target audience, you have already stated that they will all have the old service started and enabled.
Can you please explain me how I am supposed to test whether the google-network-daemon service is already running when upgrading from a version which does not include the google-network-daemon service? Thanks, Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19/06/18 19:50, John Paul Adrian Glaubitz wrote:
On 06/19/2018 12:17 PM, Simon Lees wrote:
I'm not sure how checking if the old service was started / enabled before starting / enabling the new services will cause your package to be unusable by your target audience, you have already stated that they will all have the old service started and enabled.
Can you please explain me how I am supposed to test whether the google-network-daemon service is already running when upgrading from a version which does not include the google-network-daemon service?
Thanks, Adrian
You said previously that you were replacing one old service with two new ones, obviously you'd be testing if the old service was running/enabled before stopping and disabling it then using that information to decide whether to enable the two replacement services. -- 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
On Tue, 19 Jun 2018 12:20:59 +0200 John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
On 06/19/2018 12:17 PM, Simon Lees wrote:
I'm not sure how checking if the old service was started / enabled before starting / enabling the new services will cause your package to be unusable by your target audience, you have already stated that they will all have the old service started and enabled.
Can you please explain me how I am supposed to test whether the google-network-daemon service is already running when upgrading from a version which does not include the google-network-daemon service?
Thanks, Adrian
I expect to see code like you have there: if [ -f /usr/lib/systemd/system/google-ip-forwarding-daemon.service ]; then systemctl stop --no-block google-ip-forwarding-daemon systemctl disable google-ip-forwarding-daemon.service FROM_OLD=1 fi if [ -f /usr/lib/systemd/system/google-network-setup.service ]; then systemctl stop --no-block google-network-setup systemctl disable google-network-setup.service FROM_OLD=${FROM_OLD}1 fi if [ "$FROM_OLD" == "11" ] then systemctl enable google-network-daemon.service systemctl start google-network-daemon.service fi so it will enable and start new service only if two that you are replacing was enabled. Josef -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Jun 19, 2018 at 6:50 AM Josef Reidinger <jreidinger@suse.cz> wrote:
On Tue, 19 Jun 2018 12:20:59 +0200 John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
On 06/19/2018 12:17 PM, Simon Lees wrote:
I'm not sure how checking if the old service was started / enabled before starting / enabling the new services will cause your package to be unusable by your target audience, you have already stated that they will all have the old service started and enabled.
Can you please explain me how I am supposed to test whether the google-network-daemon service is already running when upgrading from a version which does not include the google-network-daemon service?
Thanks, Adrian
I expect to see code like you have there:
if [ -f /usr/lib/systemd/system/google-ip-forwarding-daemon.service ]; then systemctl stop --no-block google-ip-forwarding-daemon systemctl disable google-ip-forwarding-daemon.service FROM_OLD=1 fi if [ -f /usr/lib/systemd/system/google-network-setup.service ]; then systemctl stop --no-block google-network-setup systemctl disable google-network-setup.service FROM_OLD=${FROM_OLD}1 fi if [ "$FROM_OLD" == "11" ] then systemctl enable google-network-daemon.service systemctl start google-network-daemon.service fi
I'd go one step further and say that you should check if it's enabled: if systemctl -q is-enabled google-ip-forwarding-daemon.service; then if systemctl -q is-active google-ip-forwarding-daemon.service; then FROM_OLD_ACTIVE=1 fi systemctl stop --no-block google-ip-forwarding-daemon systemctl disable google-ip-forwarding-daemon.service FROM_OLD=1 fi if systemctl -q is-enabled google-network-setup.service; then if systemctl -q is-active google-network-setup.service; then FROM_OLD_ACTIVE=${FROM_OLD_ACTIVE}1 fi systemctl stop --no-block google-network-setup systemctl disable google-network-setup.service FROM_OLD=${FROM_OLD}1 fi if [ "$FROM_OLD" == "11" ]; then systemctl enable google-network-daemon.service if [ "$FROM_OLD_ACTIVE" == "11" ]; then systemctl start google-network-daemon.service fi fi -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/19/2018 04:51 AM, Simon Lees wrote:
It doesn't matter how "special / specific" the package is packages enabling or starting there own services when they are not enabled are against openSUSE's packaging requirements and will be rejected by the package review team.
What do you suggest then we tell our customer then if we are unable or unwilling to resolve the issue in the way they prefer? Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19/06/18 16:52, John Paul Adrian Glaubitz wrote:
On 06/19/2018 04:51 AM, Simon Lees wrote:
It doesn't matter how "special / specific" the package is packages enabling or starting there own services when they are not enabled are against openSUSE's packaging requirements and will be rejected by the package review team.
What do you suggest then we tell our customer then if we are unable or unwilling to resolve the issue in the way they prefer?
Adrian
Now that you are talking about a customer I presume you are making this change mostly for SUSE, in which case you can tell them that while there preferred solution was good and worked, in order to comply with SUSE's packaging policy (the same as openSUSE's) to meet the standards required by SUSE's Product / Release managers you had to add some additional checks. -- 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
Hi Adrian, On 18.06.2018 22:46, John Paul Adrian Glaubitz wrote:
In generally I would agree with your stance. However, google-compute-engine is a package for a very specific purpose, namely the instance initialization and management in Google's GCE cloud.
can you determine somehow if you are in a GCE instance? some /proc/foo or something like that? And just enable/start it if that's the case? Then the "tumbleweed user who installs all crap on earth" case is discharged. And the "starts in OBS test install" is done with, too ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Jun 18 2018, John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
Index: google-compute-engine.spec =================================================================== --- google-compute-engine.spec (revision 4c54794cf9a7b720f0f1091d2a152b0e) +++ google-compute-engine.spec (working copy) @@ -169,7 +169,23 @@ %post init %if 0%{?suse_version} > 1140 %service_add_post google-accounts-daemon.service google-clock-skew-daemon.service google-instance-setup.service google-network-daemon.service google-shutdown-scripts.service google-startup-scripts.service -%else + if [ -f /usr/lib/systemd/system/google-ip-forwarding-daemon.service ]; then + systemctl stop --no-block google-ip-forwarding-daemon + systemctl disable google-ip-forwarding-daemon.service + fi + if [ -f /usr/lib/systemd/system/google-network-setup.service ]; then + systemctl stop --no-block google-network-setup + systemctl disable google-network-setup.service + fi + if [ "$1" == "2" ] && ! [ -e /.buildenv ]; then + systemctl enable google-network-daemon.service + systemctl start google-network-daemon.service + fi +%else + if [ "$1" == "2" ] && ! [ -e /.buildenv ]; then + service google-network-daemon start + fi +
I think it would be better to do that in a posttrans script. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Montag, 18. Juni 2018, 17:30:45 CEST schrieb John Paul Adrian Glaubitz:
On 06/18/2018 05:22 PM, Robert Schweikert wrote:
There is something wrong with the logic. OBS does an install test, not an "upgrade", so the services that get replaced are not running and thus the new service should not be started. The service should only be started and enabled on package upgrade.
I thought that as well, but according to the documentation, "$1" is equal to "2" for upgrades and that's what I am testing:
if [ "$1" == "2" ]; then service google-network-daemon start fi
This fails during build.
However, when I add testing for "/.buildenv" as suggested by Marcus, it works:
if [ "$1" == "2" ] && ! [ -e /.buildenv ]; then service google-network-daemon start fi
Do you have try with?: if [ $1 -eq 2 ]; then service google-network-daemon start fi See: https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets Gruß Eric -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/18/2018 06:00 PM, Eric Schirra wrote:
Do you have try with?:
if [ $1 -eq 2 ]; then service google-network-daemon start fi
See: https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets
Yes, that doesn't make any difference. Putting it into quotes just turns the integer expression into a string. Thus, it doesn't really make a difference whether you compare $1 and 2 or "$1" and "2". However, comparing the strings has the advantage that you don't risk running into syntax error when $1 is unset: glaubitz@suse-laptop:~> if [ $1 -ne 0 ] ; then echo "Hello" ; fi bash: [: -ne: unary operator expected glaubitz@suse-laptop:~> if ! [ "$1" == "0" ] ; then echo "Hello" ; fi Hello glaubitz@suse-laptop:~> As mentioned before, the problem is that the build fails because osc tries installing the package after building it which will also invoke the service commands. What I don't understand is that for the test installation, "$1" is equal to "2". But I assume that's because it's testing both upgrades as well as installation. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Mon, 18 Jun 2018, John Paul Adrian Glaubitz wrote:
glaubitz@suse-laptop:~> if [ $1 -ne 0 ] ; then echo "Hello" ; fi bash: [: -ne: unary operator expected glaubitz@suse-laptop:~> if ! [ "$1" == "0" ] ; then echo "Hello" ; fi Hello
( t() { printf "$1: "; if [ 0$1 -ne 0 ] ; then printf "Hello" ; fi ; printf "\n"; }; t ; t 0 ; t 1; t 2; ) : 0: 1: Hello 2: Hello HTH, -dnh -- $max = [$a => $b] -> [ $a <= $b ]; ## Simon Cozens -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 06/19/2018 12:00 AM, David Haller wrote:
( t() { printf "$1: "; if [ 0$1 -ne 0 ] ; then printf "Hello" ; fi ; printf "\n"; }; t ; t 0 ; t 1; t 2; ) : 0: 1: Hello 2: Hello
Yes, this is an alternative approach, this trick is actually being used in the configure script of OpenJDK. But whether I use this approach or the string conversion doesn't really change the end result in this particular context. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (13)
-
Andreas Schwab -
David Haller -
Eric Schirra -
Johannes Meixner -
John Paul Adrian Glaubitz -
Josef Reidinger -
Michael Matz -
Neal Gompa -
Richard Brown -
Robert Schweikert -
Simon Lees -
Stefan Seyfried -
Thorsten Kukuk