[opensuse-packaging] Changing %_libexecdir to /usr/libexec
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);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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 -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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 ;) -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
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,. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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. -- 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
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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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. -- 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
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... -- 真実はいつも一つ！/ 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
participants (7)
-
Andreas Schwab -
Dr. Werner Fink -
Jan Engelhardt -
Martin Wilck -
Michael Schroeder -
Neal Gompa -
Stasiek Michalski