Hello, On Feb 12 15:02 Marcus Meissner wrote:

On Wed, Feb 12, 2014 at 02:59:02PM +0100, Johannes Meixner wrote:

...

Assume an older version of package "foobar" that provided both foo.service and bar.service as described in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines is already installed.

Now a newer version of "foobar" does no longer provide bar.service (but foo.service is still provided).

What is the correct way in foobar.spec to deregister bar.service when updating the package "foobar"?

...

The _old_ package is supposed to deregister the services it brings ...

The new one should not need to care about that.

Please explain how an already installed older version of package "foobar" that provided both foo.service and bar.service should deregister bar.service? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

В Wed, 12 Feb 2014 16:30:06 +0100 Sascha Peilicke пишет:

rpm --eval %service_del_preun Is --no-reload in this case really correct? It leaves systemd with old definition still in memory leading to unpredictable behavior until next daemon-reload or reboot. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hello, On Feb 12 16:30 Sascha Peilicke wrote (excerpt):

On Wednesday 12 February 2014 14:59:02 Johannes Meixner wrote:

...

https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines only talks about "Register services in install scripts"

Assume an older version of package "foobar" that provided both foo.service and bar.service as described in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines is already installed.

Now a newer version of "foobar" does no longer provide bar.service (but foo.service is still provided).

I hope this is not related to cups.socket?

Of course it is. I need to ensure that cupsd works for SLE12 in the same plain and simple way for printing in a network as it did for SLE11. For enterprise usage I cannot play around with features that are not yet enterprise ready to be used by default out of the box, cf. https://bugzilla.novell.com/show_bug.cgi?id=857372#c66 Therefore for SLE12 there can be neither cups.socket nor cups.path provided in systemd's unitdir. Instead I provide them as templates in /usr/share/doc/packages/cups/systemd/ so that admins can make their own individual systemd unit files for socket activation and/or path activation as they need it for their particular cases. It is all only about what is activated and used by default. No systemd feature is blocked. Currently openSUSE:Factory and SLE12 development happen aligned. When SLE12 development is done, anybody who likes can take over maintainership for CUPS for openSUSE. I would really appreciate it when somebody else would like to maintain that software.

...

What is the correct way in foobar.spec to deregister bar.service when updating the package "foobar"?

I would like to use something like --------------------------------------------------- %pre %service_add_pre foo.service %service_del_pre bar.service

%post %service_add_post foo.service %service_del_post bar.service ---------------------------------------------------

I found "service_del_post" only mentioned in http://lists.opensuse.org/opensuse-packaging/2011-06/msg00160.html

That is a typo. If you read on, the pasted spec file uses

%service_del_postun (the 'un' was missing')

No typo, see below.

rpm --eval %service_del_preun

Ah! Many thanks for that info. On my openSUSE 13.1 machine I get: ----------------------------------------------------------------- # rpm --eval %service_del_pre %service_del_pre # rpm --eval %service_del_post %service_del_post ----------------------------------------------------------------- which seems to indicate that there is no such macro defined. In the old cups package there is in cups.spec (see "osc cat Printing cups cups.spec"): ------------------------------------------------------------------------ %pre /usr/sbin/groupadd -g 71 -o -r ntadmin 2>/dev/null || : %if 0%{?have_systemd} %service_add_pre cups.service cups.socket cups.path %endif exit 0 %post %{fillup_and_insserv -ny cups cups} %if 0%{?have_systemd} %service_add_post cups.service cups.socket cups.path %endif exit 0 %preun %stop_on_removal cups %if 0%{?have_systemd} %service_del_preun cups.service cups.socket cups.path %endif exit 0 %postun %restart_on_update cups %{insserv_cleanup} %if 0%{?have_systemd} %service_del_postun cups.service cups.socket cups.path %endif exit 0 ------------------------------------------------------------------------ In my current tentative new package there is in cups.spec (see "osc cat home:jsmeix:branches:Printing cups cups.spec") here without comments: ------------------------------------------------------------------------ %pre /usr/sbin/groupadd -g 71 -o -r ntadmin 2>/dev/null || : %if 0%{?have_systemd} %service_add_pre cups.service %endif exit 0 %post %if 0%{?have_systemd} %service_add_post cups.service %else %{fillup_and_insserv -ny cups cups} %endif exit 0 %preun %if 0%{?have_systemd} %service_del_preun cups.service cups.socket cups.path %else %stop_on_removal cups %endif exit 0 %postun %if 0%{?have_systemd} %service_del_postun cups.service cups.socket cups.path %else %restart_on_update cups %{insserv_cleanup} %endif exit 0 ------------------------------------------------------------------------ When I do a RPM update I get those dangling symlinks on my openSUSE 13.1 system: ------------------------------------------------------------------------ # for f in $( find /etc/systemd/system | grep cups ) ; do file $f ; done /etc/systemd/system/multi-user.target.wants/cups.path: broken symbolic link to `/usr/lib/systemd/system/cups.path' /etc/systemd/system/multi-user.target.wants/cups.service: symbolic link to `/usr/lib/systemd/system/cups.service' /etc/systemd/system/sockets.target.wants/cups.socket: broken symbolic link to `/usr/lib/systemd/system/cups.socket' ------------------------------------------------------------------------ Additionally (I had cups.socket and cups.path active but cups.service was inactive before the update) I get after the update on my openSUSE 13.1 system: ------------------------------------------------------------------------ # systemctl list-unit-files | egrep 'print|cups' configure-printer@.service static cups.service enabled printer.target static # systemctl list-units | egrep 'print|cups' cups.path not-found active waiting cups.path cups.socket not-found active listening cups.socket # systemctl status cups.socket cups.socket Loaded: not-found (Reason: No such file or directory) Active: active (listening) since Wed 2014-02-12 13:56:17 CET; 3h 7min ago Feb 12 13:56:17 d180 systemd[1]: Stopping CUPS Printing Service Sockets. Feb 12 13:56:17 d180 systemd[1]: Starting CUPS Printing Service Sockets. Feb 12 13:56:17 d180 systemd[1]: Listening on CUPS Printing Service Sockets. # systemctl status cups.path cups.path Loaded: not-found (Reason: No such file or directory) Active: active (waiting) since Wed 2014-02-12 13:56:17 CET; 3h 7min ago Feb 12 13:56:17 d180 systemd[1]: Stopping CUPS Printer Service Spool. Feb 12 13:56:17 d180 systemd[1]: Starting CUPS Printer Service Spool. Feb 12 13:56:17 d180 systemd[1]: Started CUPS Printer Service Spool. ------------------------------------------------------------------------ What I would like to see is that both cups.socket and cups.path got automatically disabled and stopped after the update. I did "rpm -Uhvv" when updating cups and in its output I can see this ordering of the install/erase and scriptlets on my openSUSE 13.1 system: ----------------------------------------------------------------------- # egrep 'scriptlet|install:|erase:' /tmp/rpm.out D: install: cups-libs-1.5.4-144.1 has 33 files D: %post(cups-libs-1.5.4-144.1.i586): scriptlet start D: install: cups-client-1.5.4-144.1 has 41 files D: install: cups-1.5.4-144.1 has 1078 files D: %pre(cups-1.5.4-144.1.i586): scriptlet start D: %post(cups-1.5.4-144.1.i586): scriptlet start D: erase: cups-1.5.4-12.4.1 has 1072 files D: %preun(cups-1.5.4-12.4.1.i586): scriptlet start D: %postun(cups-1.5.4-12.4.1.i586): scriptlet start D: erase: cups-client-1.5.4-12.4.1 has 41 files D: erase: cups-libs-1.5.4-12.4.1 has 33 files D: %postun(cups-libs-1.5.4-12.4.1.i586): scriptlet start -----------------------------------------------------------------------

From that I thought I need to do something in %pre(cups-1.5.4-144.1.i586) scriptlet and/or %post(cups-1.5.4-144.1.i586): scriptlet of the new package to get things right.

But from what Marcus Meissner wrote here it seems this is perhaps not an issue in how I package cups but an issue in systemd? Shouldn't %service_del_preun cups.service cups.socket cups.path and %service_del_postun cups.service cups.socket cups.path in the old package do "the right thing"? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Feb 12 20:26 Andrey Borzenkov wrote (excerpt):

? Wed, 12 Feb 2014 17:13:10 +0100 (CET) Johannes Meixner ?????:

...

On my openSUSE 13.1 machine I get: ----------------------------------------------------------------- # rpm --eval %service_del_pre %service_del_pre # rpm --eval %service_del_post %service_del_post ----------------------------------------------------------------- which seems to indicate that there is no such macro defined.

bor@opensuse:~> rpm -qf /etc/rpm/macros.systemd systemd-rpm-macros-2-15.1.noarch

on my openSUSE 13.1 machine: ----------------------------------------------------------------- # rpm -qf /etc/rpm/macros.systemd systemd-rpm-macros-2-15.1.noarch ----------------------------------------------------------------- -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hello, On Feb 12 20:45 Andrey Borzenkov wrote (excerpt):

I meant %service_del_preun, %service_del_postun

I use them already in the old installed package according to https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines (at least I don't see that I did something wrong there) but it seems they do not work as I had expected, see my other (long) mail here in this thread. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wednesday 12 February 2014 18:04:39 Frederic Crozat wrote:

Le mercredi 12 février 2014 à 17:13 +0100, Johannes Meixner a écrit :

...

Hello,

On Feb 12 16:30 Sascha Peilicke wrote (excerpt):

...

On Wednesday 12 February 2014 14:59:02 Johannes Meixner wrote:

...

https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines only talks about "Register services in install scripts"

Assume an older version of package "foobar" that provided both foo.service and bar.service as described in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines is already installed.

Now a newer version of "foobar" does no longer provide bar.service (but foo.service is still provided).

I hope this is not related to cups.socket?

Of course it is.

I need to ensure that cupsd works for SLE12 in the same plain and simple way for printing in a network as it did for SLE11. For enterprise usage I cannot play around with features that are not yet enterprise ready to be used by default out of the box, cf. https://bugzilla.novell.com/show_bug.cgi?id=857372#c66

I don't know if it's better to add comment #110 or just replying here. Just because you have a daemon (cups) listen on 0.0.0.0 for UDP packets doesn't mean "The Internet" (citing comment #66) can attack you. I'd argue that 99% of openSUSE user's machines sit in a local NAT'ed network (behind an adsl router). That's as insecure as OpenSSH running is. And your SuSEFirewall still blocks the port by default. So with pristine settings, you are safe. Letting the service _not_ listen on any interface simply means it can't do it's job. Listening for CUPS printer broadcasts in that case.

...

Therefore for SLE12 there can be neither cups.socket nor cups.path provided in systemd's unitdir. Instead I provide them as templates in /usr/share/doc/packages/cups/systemd/ so that admins can make their own individual systemd unit files for socket activation and/or path activation as they need it for their particular cases.

SLE12 and openSUSE have identical goals here, there's no need to distinguish. Or do you want to maintain cups' init script for the next 13 years? I'd say go with the system service. Either way, I'm happy to take the minimal burden of maintaining cups. In fact I already prepared the version update (we're ancient ATM).

Or you continue to ship them and change systemd-preset-branding-SLE to not enable cups.path/cups.path. This branding package has been created exactly to handle behaviour difference between SLE and openSUSE..

Exactly. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hello, On Feb 12 18:04 Frederic Crozat wrote (excerpt):

...

...

On Wednesday 12 February 2014 14:59:02 Johannes Meixner wrote:

...

https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines only talks about "Register services in install scripts"

Assume an older version of package "foobar" that provided both foo.service and bar.service as described in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines is already installed.

Now a newer version of "foobar" does no longer provide bar.service (but foo.service is still provided).

... Or you continue to ship them...

No red herring please. Can we please not wander from the subject but stay on my generic question that applies to all packages: How exactly should the RPM spec file scriptles be in package foobar version 1 versus foobar version 2 when foobar version 1 provides foo.service and bar.service but foobar version 2 still provides only foo.service but does no longer provide bar.service? According to "Register services in install scripts" in http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines foobar.spec for version 1 should be ------------------------------------------------------------------------ %pre %service_add_pre foo.service bar.service %post %service_add_post foo.service bar.service %preun %service_del_preun foo.service bar.service %postun %service_del_postun foo.service bar.service ------------------------------------------------------------------------ My question is how should foobar.spec for version 2 look like? According to http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines I imagine foobar.spec for version 2 could be either ------------------------------------------------------------------------ %pre %service_add_pre foo.service %post %service_add_post foo.service %preun %service_del_preun foo.service %postun %service_del_postun foo.service ------------------------------------------------------------------------ or ------------------------------------------------------------------------ %pre %service_add_pre foo.service %post %service_add_post foo.service %preun %service_del_preun foo.service bar.service %postun %service_del_postun foo.service bar.service ------------------------------------------------------------------------ Can someone tell me if one of the two above is the right one or provide information what the right one is? Preferably I would like if http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines get enhanced accordingly. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hello, On Feb 13 12:51 Frederic Crozat wrote (excerpt):

Le jeudi 13 février 2014 à 11:43 +0100, Johannes Meixner a écrit :

...

How exactly should the RPM spec file scriptles be in package foobar version 1 versus foobar version 2 when foobar version 1 provides foo.service and bar.service but foobar version 2 still provides only foo.service but does no longer provide bar.service?

This is not handled by the macros (and AFAIK, it wasn't the case with the initscripts macros either). You'll have to write this manually using RPM triggers, to properly stop the services and disable them.

Is there a recommended and prehaps already somewhere documented way how one should do that? I would do in a foobar version 2 RPM scriptlet something like ------------------------------------------------------------------------ for f in /etc/systemd/system/*/bar.service do if test -L $f -a ! -e $f then systemctl stop bar.service systemctl disable bar.service fi done ------------------------------------------------------------------------ My reasoning for the "test -L $f -a ! -e $f" therein is: To be safe I like to stop and disable bar.service only when its systemd setup is broken and therefore I test if /etc/systemd/system/*/bar.service is a broken symbolic link. I hope that this test is reasonably sufficient to determine whether or not the bar.service systemd setup is broken. When foobar version 2 does no longer provide bar.service the admin may have installed his own bar.service unit file so that /etc/systemd/system/*/bar.service is not a broken symbolic link and in this case I do not want to stop or disable bar.service. Is my reasoning correct or should I easily just simply run ------------------------------------------------------------------------ systemctl stop bar.service systemctl disable bar.service ------------------------------------------------------------------------ in an unconditioned way? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer