Hi folks,
OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec. This was proposed in July on the opensuse-packaging list with only Thorsten and Jan replying (Jan being in favor).
I don't want to merge it right now without giving you some time to discuss this change. So please, if you have good reasons why this is a bad idea please speak up!
If there are no strong objections, I'll merge the request at the end of next weak.
Cheers, Michael.
On Fri, 2019-10-18 at 08:32 +0000, Michael Schroeder wrote:
Hi folks,
OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec. This was proposed in July on the opensuse-packaging list with only Thorsten and Jan replying (Jan being in favor).
I don't want to merge it right now without giving you some time to discuss this change. So please, if you have good reasons why this is a bad idea please speak up!
If there are no strong objections, I'll merge the request at the end of next weak.
Cheers, Michael.
-- Michael Schroeder mls@suse.de SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
Thanks for the heads-up.
For the record I am fond of the idea.
Hi,
Am Freitag, 18. Oktober 2019, 10:32:29 CEST schrieb Michael Schroeder:
Hi folks,
OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec. This was proposed in July on the opensuse-packaging list with only Thorsten and Jan replying (Jan being in favor).
I don't want to merge it right now without giving you some time to discuss this change. So please, if you have good reasons why this is a bad idea please speak up!
This would break some packages like purpose, which call binaries inside libexec from a libary which is 32/64-bit co-installable using baselibs.conf.
What's the right way to handle that?
Cheers, Fabian
If there are no strong objections, I'll merge the request at the end of next weak.
Cheers, Michael.
On Fri, Oct 18, 2019 at 4:45 AM Fabian Vogt fvogt@suse.de wrote:
Hi,
Am Freitag, 18. Oktober 2019, 10:32:29 CEST schrieb Michael Schroeder:
Hi folks,
OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec. This was proposed in July on the opensuse-packaging list with only Thorsten and Jan replying (Jan being in favor).
I don't want to merge it right now without giving you some time to discuss this change. So please, if you have good reasons why this is a bad idea please speak up!
This would break some packages like purpose, which call binaries inside libexec from a libary which is 32/64-bit co-installable using baselibs.conf.
What's the right way to handle that?
This is already broken right now as it is currently packaged. But if you want to fix it, the way you'd do it is by splitting out that binary into a subpackage and have the library packages have a dependency on that subpackage containing the libexec binaries.
On Friday 2019-10-18 10:44, Fabian Vogt wrote:
OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec. This was proposed in July on the opensuse-packaging list
This would break some packages like purpose, which call binaries inside libexec from a libary which is 32/64-bit co-installable using baselibs.conf.
What's the right way to handle that?
A 32-bit library can invoke(*) a 64-bit program with no problem. Then you just need to make sure that these two entities live in packages such that the combinations are always installable. The current state in o:F/purpose suggests that said library package will need to "Require: purpose" to get at the "purposeprocess" executable.
(*) standard fork/execv approach. let's not consider the hypothetical way of dlopening it ;-)
On 2019/10/18 08:32:29 +0000, Michael Schroeder wrote:
Hi folks,
OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec. This was proposed in July on the opensuse-packaging list with only Thorsten and Jan replying (Jan being in favor).
I don't want to merge it right now without giving you some time to discuss this change. So please, if you have good reasons why this is a bad idea please speak up!
If there are no strong objections, I'll merge the request at the end of next weak.
Ohhmm ... what is about FHS? Ahh .. I see latest FHS knows about:
4.7. /usr/libexec : Binaries run by other programs (optional) 4.7.1. Purpose
/usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/libexec. Applications which use /usr/libexec in this way must not also use /usr/lib to store internal binaries, though they may use /usr/lib for the other purposes documented here.
Rationale Some previous versions of this document did not support /usr/libexec, despite it being standard practice in a number of environments. To accomodate this restriction, it became common practice to use /usr/lib instead. Either practice is now acceptable, but each application must choose one way or the other to organize itself.
This seems that we might get packages/applications with /usr/libexec and some with /usr/lib ... do we need an rpmlint check for Factory here?
Werner
On Fri, Oct 18, 2019 at 10:47 AM, Dr. Werner Fink werner@suse.de wrote:
On 2019/10/18 08:32:29 +0000, Michael Schroeder wrote:
Hi folks,
OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec. This was proposed in July on the opensuse-packaging list with only Thorsten and Jan replying (Jan being in favor).
I don't want to merge it right now without giving you some time to discuss this change. So please, if you have good reasons why this is a bad idea please speak up!
If there are no strong objections, I'll merge the request at the end of next weak.
Ohhmm ... what is about FHS? Ahh .. I see latest FHS knows about:
4.7. /usr/libexec : Binaries run by other programs (optional) 4.7.1. Purpose
/usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/libexec. Applications which use /usr/libexec in this way must not also use /usr/lib to store internal binaries, though they may use /usr/lib for the other purposes documented here.
Rationale Some previous versions of this document did not support /usr/libexec, despite it being standard practice in a number of environments. To accomodate this restriction, it became common practice to use /usr/lib instead. Either practice is now acceptable, but each application must choose one way or the other to organize itself.
This seems that we might get packages/applications with /usr/libexec and some with /usr/lib ... do we need an rpmlint check for Factory here?
I would assume we would just need to have a check for executable bits in /usr/lib then, it shouldn't be too hard to do considering such a check already exists for /etc iirc.
Considering this is new though, we probably shouldn't force it yet.
LCP [Stasiek] https://lcp.world
On Friday 2019-10-18 10:47, Dr. Werner Fink wrote:
On 2019/10/18 08:32:29 +0000, Michael Schroeder wrote:
OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec.
Ohhmm ... what is about FHS? Ahh .. I see latest FHS knows about:[...]
FHS had some ups and downs. This message I found would appear to summarize the past problem. https://lists.debian.org/debian-devel/2005/05/msg00565.html
This seems that we might get packages/applications with /usr/libexec and some with /usr/lib ... do we need an rpmlint check for Factory here?
What condition would need checking? Does the presence of libexec and lib constitute an error in your view?
On 2019/10/18 11:15:40 +0200, Jan Engelhardt wrote:
On Friday 2019-10-18 10:47, Dr. Werner Fink wrote:
On 2019/10/18 08:32:29 +0000, Michael Schroeder wrote:
OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec.
Ohhmm ... what is about FHS? Ahh .. I see latest FHS knows about:[...]
FHS had some ups and downs. This message I found would appear to summarize the past problem. https://lists.debian.org/debian-devel/2005/05/msg00565.html
This is old as well as the mentioned FHS therein, I'm talking about *current* FHS 3 at https://refspecs.linuxfoundation.org/fhs.shtml
This seems that we might get packages/applications with /usr/libexec and some with /usr/lib ... do we need an rpmlint check for Factory here?
What condition would need checking? Does the presence of libexec and lib constitute an error in your view?
IMHO if we move from /usr/lib to /usr/libexec then all packages should do this. Nevertheless we might focus some more problems here as well ;)
On Friday 2019-10-18 11:19, Dr. Werner Fink wrote:
This seems that we might get packages/applications with /usr/libexec and some with /usr/lib ... do we need an rpmlint check for Factory here?
What condition would need checking? Does the presence of libexec and lib constitute an error in your view?
IMHO if we move from /usr/lib to /usr/libexec then all packages should do this. Nevertheless we might focus some more problems here as well ;)
What I mean is that: Since libraries can live in /usr/lib [i586], you would not be able to take the presence of /usr/lib in a package as a sign that there is a missed move to libexec - unfortunately.
What might work to detect such a missed move... I guess one could search /usr/lib for DT_EXEC ELF binaries. That could run afoul of some packages with hardcoded locations, I am imaging this would occur to udev/systemd first, and then later on maybe perl, git,.
On Okt 18 2019, Jan Engelhardt wrote:
What might work to detect such a missed move... I guess one could search /usr/lib for DT_EXEC ELF binaries.
You would unlikely find some due to PIE default.
Andreas.
On Monday 2019-10-21 10:38, Andreas Schwab wrote:
On Okt 18 2019, Jan Engelhardt wrote:
What might work to detect such a missed move... I guess one could search /usr/lib for DT_EXEC ELF binaries.
You would unlikely find some due to PIE default.
That much is true, evaluating just that field won't be enough.
Since /usr/bin/file seemingly can detect the difference, rpmlint could do it in principle too.
On Okt 21 2019, Jan Engelhardt wrote:
Since /usr/bin/file seemingly can detect the difference, rpmlint could do it in principle too.
It parses the dynamic section and looks for the PIE flag.
Andreas.
Hello,
Am Freitag, 18. Oktober 2019, 10:32:29 CEST schrieb Michael Schroeder:
OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec. This was proposed in July on the opensuse-packaging list with only Thorsten and Jan replying (Jan being in favor).
I don't want to merge it right now without giving you some time to discuss this change. So please, if you have good reasons why this is a bad idea please speak up!
Not really an objection, more a question and warning:
This change could break programs with AppArmor profiles that have exec rules for binaries in /usr/lib/ - when the binary moves, the profile also needs an update.
The most obvious candidates are the /usr/lib/dovecot/* binaries - will they move to /usr/libexec/? If so, please tell me (or send a SR ;-) so that I can submit updated profiles to avoid breakage ;-)
Regards,
Christian Boltz
On Sat, Oct 19, 2019 at 4:45 PM Christian Boltz opensuse@cboltz.de wrote:
Hello,
Am Freitag, 18. Oktober 2019, 10:32:29 CEST schrieb Michael Schroeder:
OBS request 738494 from Neal will change %_libexecdir from /usr/lib to /usr/libexec. This was proposed in July on the opensuse-packaging list with only Thorsten and Jan replying (Jan being in favor).
I don't want to merge it right now without giving you some time to discuss this change. So please, if you have good reasons why this is a bad idea please speak up!
Not really an objection, more a question and warning:
This change could break programs with AppArmor profiles that have exec rules for binaries in /usr/lib/ - when the binary moves, the profile also needs an update.
The most obvious candidates are the /usr/lib/dovecot/* binaries - will they move to /usr/libexec/? If so, please tell me (or send a SR ;-) so that I can submit updated profiles to avoid breakage ;-)
The way the dovecot23 package is currently set, it defines --libexecdir as %_prefix/lib/%name rather than %_libexecdir/%name. So it won't change automatically, but it should be changed, and the AppArmor profiles should change along with it.
I would suggest changing the AppArmor profile for the libexec binaries to use path definitions like "/usr/lib{,exec}" if you want to be backwards compatible to SLE 15 / Leap 15 and older.
On Fri, 2019-10-18 at 08:32 +0000, Michael Schroeder wrote:
If there are no strong objections, I'll merge the request at the end of next weak.
FTR, weak-modules2 (package suse-module-tools) resides in /usr/lib/module-init-tools, and not only the kernel packages but every KMP out there expects it to be there. So I'll keep this location for the time being, long-term plans to be discussed.
Martin
On Thu, Nov 7, 2019 at 3:37 PM Martin Wilck Martin.Wilck@suse.com wrote:
On Fri, 2019-10-18 at 08:32 +0000, Michael Schroeder wrote:
If there are no strong objections, I'll merge the request at the end of next weak.
FTR, weak-modules2 (package suse-module-tools) resides in /usr/lib/module-init-tools, and not only the kernel packages but every KMP out there expects it to be there. So I'll keep this location for the time being, long-term plans to be discussed.
That's fine, it'd be helpful if a note in the spec was made about overriding it to continue using /usr/lib and when this will go away. That way, it can be found and fixed...
On 07/11/2019 21.45, Neal Gompa wrote:
On Thu, Nov 7, 2019 at 3:37 PM Martin Wilck Martin.Wilck@suse.com wrote:
FTR, weak-modules2 (package suse-module-tools) resides in /usr/lib/module-init-tools, and not only the kernel packages but every KMP out there expects it to be there. So I'll keep this location for the time being, long-term plans to be discussed.
That's fine, it'd be helpful if a note in the spec was made about overriding it to continue using /usr/lib and when this will go away. That way, it can be found and fixed...
/usr/lib/module-init-tools could just be a symlink to /usr/libexec/module-init-tools so that users can switch whenever they are ready. This should give a smooth migration path.
On Fri, 2019-11-08 at 10:06 +0100, Bernhard M. Wiedemann wrote:
On 07/11/2019 21.45, Neal Gompa wrote:
/usr/lib/module-init-tools could just be a symlink to /usr/libexec/module-init-tools so that users can switch whenever they are ready. This should give a smooth migration path.
Yes, I thought about that. I'm not sure about the usefulness though. Definitely, it's only useful if some day we really remove the symlink. We should probably set a calender entry because it will be forgotten otherwise; the grace period has to be several years, for SLE at least.
/usr/lib/module-init-tools is already a legacy path (IIRC module-init- tools last existed in SLE11) which we never dared to rename. Perhaps it's time to be bold and move /usr/lib/module-init-tools to /usr/libexec/suse-module-tools :-)
Martin
On Fri, Nov 8, 2019 at 4:04 PM Martin Wilck Martin.Wilck@suse.com wrote:
On Fri, 2019-11-08 at 10:06 +0100, Bernhard M. Wiedemann wrote:
On 07/11/2019 21.45, Neal Gompa wrote:
/usr/lib/module-init-tools could just be a symlink to /usr/libexec/module-init-tools so that users can switch whenever they are ready. This should give a smooth migration path.
Yes, I thought about that. I'm not sure about the usefulness though. Definitely, it's only useful if some day we really remove the symlink. We should probably set a calender entry because it will be forgotten otherwise; the grace period has to be several years, for SLE at least.
/usr/lib/module-init-tools is already a legacy path (IIRC module-init- tools last existed in SLE11) which we never dared to rename. Perhaps it's time to be bold and move /usr/lib/module-init-tools to /usr/libexec/suse-module-tools :-)
Why is this still in the distribution, then? Heck, I thought we were using kmod like everyone else already...
On Fri, 2019-11-08 at 17:09 -0500, Neal Gompa wrote:
Why is this still in the distribution, then? Heck, I thought we were using kmod like everyone else already...
Sure we are using kmod. Just the name of the directory hasn't changed. suse-module-tools was split out of module-init-tools before the latter was replaced.
Martin
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
-
Andreas Schwab -
Bernhard M. Wiedemann -
Christian Boltz -
Dr. Werner Fink -
Fabian Vogt -
Jan Engelhardt -
Martin Wilck -
Michael Schroeder -
Neal Gompa -
Richard Brown -
Stasiek Michalski