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 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 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 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 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

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

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/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

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 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 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

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 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 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/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 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, Jun 19, 2018 at 6:50 AM Josef Reidinger wrote:

On Tue, 19 Jun 2018 12:20:59 +0200 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

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 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

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

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