[opensuse-factory] Heads-Up: sysvinit-tools is no longer pulled in by systemd
Hi, Just a note to let you know that systemd is going to stop pulling in 'sysvinit-tools' package. The dep was added back in 2014 for vhangup(8) but it was no longer used, see [1] for the details. That might break packages that ignored to specify their dependencies on the tools shipped by 'sysvinit-tools' (such as pidof). Please make sure to add back the dep if your packages fall into this category. Thanks [1] https://build.opensuse.org/package/revisions/Base:System/systemd (rev 1109) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Aug 26, Franck Bui wrote:
Hi,
Just a note to let you know that systemd is going to stop pulling in 'sysvinit-tools' package. The dep was added back in 2014 for vhangup(8) but it was no longer used, see [1] for the details.
That might break packages that ignored to specify their dependencies on the tools shipped by 'sysvinit-tools' (such as pidof).
Maybe it's time to drop the pidof of sysvinit-tools (is that maintained at all anymore?) and use the pidof of procps? Which is the successor of the sysvinit-tools pidof? Thorsten
Please make sure to add back the dep if your packages fall into this category.
Thanks
[1] https://build.opensuse.org/package/revisions/Base:System/systemd (rev 1109) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2020-08-26 at 13:16 +0200, Thorsten Kukuk wrote:
On Wed, Aug 26, Franck Bui wrote:
Hi,
Just a note to let you know that systemd is going to stop pulling in 'sysvinit-tools' package. The dep was added back in 2014 for vhangup(8) but it was no longer used, see [1] for the details.
That might break packages that ignored to specify their dependencies on the tools shipped by 'sysvinit-tools' (such as pidof).
Maybe it's time to drop the pidof of sysvinit-tools (is that maintained at all anymore?) and use the pidof of procps? Which is the successor of the sysvinit-tools pidof?
There is even procps-ng - which in fact is what our 'procps' package contains. procps.spec contains a build condition for pidof; so it should be rather easy to toggle it on (and remove it from sysvinit- tools). Packages wanting to specify this dependency will best do so by specifying Requires: /bin/pidof - then there is no need to worry for the time when that switch from sysvinit-tools to procps would happen. as for sysvinit-tools: the collection is still maintained - latest released tarball was in July 2020. Cheers, Dominique
* Dominique Leuenberger / DimStar
On Wed, 2020-08-26 at 13:16 +0200, Thorsten Kukuk wrote:
On Wed, Aug 26, Franck Bui wrote:
Hi,
Just a note to let you know that systemd is going to stop pulling in 'sysvinit-tools' package. The dep was added back in 2014 for vhangup(8) but it was no longer used, see [1] for the details.
That might break packages that ignored to specify their dependencies on the tools shipped by 'sysvinit-tools' (such as pidof).
Maybe it's time to drop the pidof of sysvinit-tools (is that maintained at all anymore?) and use the pidof of procps? Which is the successor of the sysvinit-tools pidof?
There is even procps-ng - which in fact is what our 'procps' package contains. procps.spec contains a build condition for pidof; so it should be rather easy to toggle it on (and remove it from sysvinit- tools).
Packages wanting to specify this dependency will best do so by specifying Requires: /bin/pidof - then there is no need to worry for the time when that switch from sysvinit-tools to procps would happen.
as for sysvinit-tools: the collection is still maintained - latest released tarball was in July 2020.
on my Tumbleweed 20200824 pidof is provided by sysvinit-tools and procps-3.3.16-1.3.x86_64, installed, does not contain/provide pidof. ??? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Aug 26, Patrick Shanahan wrote:
on my Tumbleweed 20200824 pidof is provided by sysvinit-tools and procps-3.3.16-1.3.x86_64, installed, does not contain/provide pidof.
Correct, and that's what we will change, as procps is always installed, sysvinit-tools was only because of systemd and will be no longer in the future. The procps sources do contain pidof. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2020-08-26 at 14:22 +0200, Thorsten Kukuk wrote:
On Wed, Aug 26, Patrick Shanahan wrote:
on my Tumbleweed 20200824 pidof is provided by sysvinit-tools and procps-3.3.16-1.3.x86_64, installed, does not contain/provide pidof.
Correct, and that's what we will change, as procps is always installed, sysvinit-tools was only because of systemd and will be no longer in the future. The procps sources do contain pidof.
Created submissions (to the devel projects) for: * sysvinit: sr#829755 (drop pidof) * procps: sr#829757 (add pidof) Cheers, Dominique
On Wed, 2020-08-26 at 14:46 +0200, Dominique Leuenberger / DimStar wrote:
On Wed, 2020-08-26 at 14:22 +0200, Thorsten Kukuk wrote:
On Wed, Aug 26, Patrick Shanahan wrote:
on my Tumbleweed 20200824 pidof is provided by sysvinit-tools and procps-3.3.16-1.3.x86_64, installed, does not contain/provide pidof.
Correct, and that's what we will change, as procps is always installed, sysvinit-tools was only because of systemd and will be no longer in the future. The procps sources do contain pidof.
Created submissions (to the devel projects) for: * sysvinit: sr#829755 (drop pidof) * procps: sr#829757 (add pidof)
Meh - I just see that procps installs pidof to /usr/bin whereas before we had it in /bin (and /sbin - why ever) So this would still break the dependency on xdm :(
On Wed, Aug 26, Dominique Leuenberger / DimStar wrote:
On Wed, 2020-08-26 at 14:22 +0200, Thorsten Kukuk wrote:
On Wed, Aug 26, Patrick Shanahan wrote:
on my Tumbleweed 20200824 pidof is provided by sysvinit-tools and procps-3.3.16-1.3.x86_64, installed, does not contain/provide pidof.
Correct, and that's what we will change, as procps is always installed, sysvinit-tools was only because of systemd and will be no longer in the future. The procps sources do contain pidof.
Created submissions (to the devel projects) for: * sysvinit: sr#829755 (drop pidof) * procps: sr#829757 (add pidof)
And we had already: SR#829746 and SR#829745 ... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2020-08-26 at 14:53 +0200, Thorsten Kukuk wrote:
And we had already: SR#829746 and SR#829745 ...
In my defense - I had a sysvinit submission lingering around before with the version update, so I just added the pidof removal there too. for procpswe can clearly favor yours, which was first (mine revoked) This still leaves the issue I'd seen though: procps installs pidof to /usr/bin, whereas sysvinit-tools has it in /bin and /sbin, which is also what xdm currently requires.
On Wed, Aug 26, Dominique Leuenberger / DimStar wrote:
On Wed, 2020-08-26 at 14:53 +0200, Thorsten Kukuk wrote:
And we had already: SR#829746 and SR#829745 ...
In my defense - I had a sysvinit submission lingering around before with the version update, so I just added the pidof removal there too.
for procpswe can clearly favor yours, which was first (mine revoked)
I don't care which one we use, especially as the procps change is identical in both submissions.
This still leaves the issue I'd seen though: procps installs pidof to /usr/bin, whereas sysvinit-tools has it in /bin and /sbin, which is also what xdm currently requires.
To make the usrbin move easier: let's use /usr/bin/pidof Which means we need to adjust xdm and lsb. Where the question is, if they really need this requires, as procps is really something always installed. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2020-08-26 16:22, Thorsten Kukuk wrote:
Which means we need to adjust xdm and lsb. Where the question is, if they really need this requires, as procps is really something always installed.
Always? $ rpm -e procps --test error: Failed dependencies: procps is needed by (installed) zypper-1.14.37-lp152.2.5.4.x86_64 and inside the SUSE containers that you, Richard et al are working on/towards, I imagine there may not even be a zypper present. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2020-08-26 at 16:41 +0200, Jan Engelhardt wrote:
On Wednesday 2020-08-26 16:22, Thorsten Kukuk wrote:
Which means we need to adjust xdm and lsb. Where the question is, if they really need this requires, as procps is really something always installed.
Always?
$ rpm -e procps --test error: Failed dependencies: procps is needed by (installed) zypper-1.14.37- lp152.2.5.4.x86_64
and inside the SUSE containers that you, Richard et al are working on/towards, I imagine there may not even be a zypper present.
Inside those containers there will almost certainly be 'busybox-procps' In those cases, having a package with a hard requires for the 'procps' package is actually a pain in the posterior. So Thorsten's question is valid, packages should only require 'procps' if they really, really need _the procps package_, else it should always be safe to assume the system will have something that provides procps functionality. -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2020-08-26 16:49, Richard Brown wrote:
On Wed, 2020-08-26 at 16:41 +0200, Jan Engelhardt wrote:
On Wednesday 2020-08-26 16:22, Thorsten Kukuk wrote:
Which means we need to adjust xdm and lsb [for pidof]. Where the question is, if they really need this requires, as procps is really something always installed.
Always?
$ rpm -e procps --test error: Failed dependencies: procps is needed by (installed) zypper-1.14.37- lp152.2.5.4.x86_64
and inside the SUSE containers that you, Richard et al are working on/towards, I imagine there may not even be a zypper present.
Inside those containers there will almost certainly be 'busybox-procps'[...] So Thorsten's question is valid, packages should only require 'procps' if they really, really need _the procps package_, else it should always be safe to assume the system will have something that provides procps functionality.
That is what I was aiming at: it's not safe to assume so in the context of the upcoming change of the provider of the pidof utility. As shown, almost nothing depends on procps. Such system can exist, e.g. dnf folks that have thrown out zypper :-) If the /usr/bin/pidof file now moves from sysvinit-tools to procps, but procps is not installed (and hence also will not be updated for said dnf system), the system as a whole no longer has /usr/bin/pidof. xdm would therefore need a Require: /usr/bin/pidof. /etc/X11/xdm/RunChooser:pidof -s kdm > /dev/null 2>&1 /etc/X11/xdm/RunChooser:if test $? -eq 0 -a -x $kdmdesktop ; then ... /etc/X11/xdm/Xsession:/sbin/pidof -s wdm > /dev/null 2>&1 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Aug 26, 2020 at 12:16 PM Jan Engelhardt
xdm would therefore need a Require: /usr/bin/pidof.
/etc/X11/xdm/RunChooser:pidof -s kdm > /dev/null 2>&1 /etc/X11/xdm/RunChooser:if test $? -eq 0 -a -x $kdmdesktop ; then ... /etc/X11/xdm/Xsession:/sbin/pidof -s wdm > /dev/null 2>&1
So, systemctl show --property MainPID --value $SERVICE_THAT_STARTS_WISHED_DM... and we are set.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2020-08-26 18:16, Jan Engelhardt wrote:
On Wednesday 2020-08-26 16:49, Richard Brown wrote:
On Wed, 2020-08-26 at 16:41 +0200, Jan Engelhardt wrote:
On Wednesday 2020-08-26 16:22, Thorsten Kukuk wrote:
Which means we need to adjust xdm and lsb [for pidof]. Where the question is, if they really need this requires, as procps is really something always installed.
As shown, almost nothing depends on procps. Such system can exist, e.g. dnf folks that have thrown out zypper :-)
Oh well, it's long done: Tue Feb 4 21:06:34 UTC 2014 - coolo@suse.com - /etc/X11/xdm/RunChooser calls pidof, so require it -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Aug 26, Jan Engelhardt wrote:
On Wednesday 2020-08-26 16:22, Thorsten Kukuk wrote:
Which means we need to adjust xdm and lsb. Where the question is, if they really need this requires, as procps is really something always installed.
Always?
$ rpm -e procps --test error: Failed dependencies: procps is needed by (installed) zypper-1.14.37-lp152.2.5.4.x86_64
So if you don't have a special appliance without zypper, it's there. But would be better to add it to a base pattern, too, as most packages using pidof don't require it.
and inside the SUSE containers that you, Richard et al are working on/towards, I imagine there may not even be a zypper present.
zypper is not always there, but all containers contain procps :) Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Aug 26, 2020 at 6:23 AM Franck Bui
Hi,
Just a note to let you know that systemd is going to stop pulling in 'sysvinit-tools' package. The dep was added back in 2014 for vhangup(8) but it was no longer used, see [1] for the details.
That might break packages that ignored to specify their dependencies on the tools shipped by 'sysvinit-tools' (such as pidof).
There are also buggy unit files, like ack killproc /usr/lib/systemd/system /usr/lib/systemd/system/openvpn@.service 12:ExecReload=/sbin/killproc -p /run/openvpn/%i.pid -HUP /usr/sbin/openvpn That use tools from this package. that line is all wrong) should be ExecReload=/usr/bin/kill -HUP $MAINPID relying on pid files is known to be racy.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/26/20 4:54 PM, Cristian Rodríguez wrote:
That use tools from this package. that line is all wrong) should be
ExecReload=/usr/bin/kill -HUP $MAINPID
relying on pid files is known to be racy..
https://build.opensuse.org/request/show/829828 Thanks. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 27, Franck Bui wrote:
On 8/26/20 4:54 PM, Cristian Rodríguez wrote:
That use tools from this package. that line is all wrong) should be
ExecReload=/usr/bin/kill -HUP $MAINPID
relying on pid files is known to be racy..
But with your second change, the first one (Requires sysvinit-tools) should be obsolete, as you removed the usage of tools from sysvinit-tools. So please don't introduce not necessary dependencies. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/27/20 8:44 AM, Thorsten Kukuk wrote:
But with your second change, the first one (Requires sysvinit-tools) should be obsolete, as you removed the usage of tools from sysvinit-tools. So please don't introduce not necessary dependencies.
Unfortunately that's not possible because it's still needed in other places, see %post that relies on checkproc(8) for example. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 27, Franck Bui wrote:
On 8/27/20 8:44 AM, Thorsten Kukuk wrote:
But with your second change, the first one (Requires sysvinit-tools) should be obsolete, as you removed the usage of tools from sysvinit-tools. So please don't introduce not necessary dependencies.
Unfortunately that's not possible because it's still needed in other places, see %post that relies on checkproc(8) for example.
That code can be removed, even SLES12 as our oldest active systemd based distribution has that migration code already. So it will never be executed anymore. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/27/20 9:21 AM, Thorsten Kukuk wrote:
That code can be removed, even SLES12 as our oldest active systemd based distribution has that migration code already. So it will never be executed anymore.
OK then let's wait for the maintainer to review this sr and once accepted or declined, we'll get rid of that migration code as well as the dep on sysvinit-tools when the package is built with systemd support. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (7)
-
Cristian Rodríguez -
Dominique Leuenberger / DimStar -
Franck Bui -
Jan Engelhardt -
Patrick Shanahan -
Richard Brown -
Thorsten Kukuk