[opensuse-factory] 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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2019-10-18 at 08:32 +0000, Michael Schroeder wrote:
Thanks for the heads-up. For the record I am fond of the idea. -- 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
Hi, Am Freitag, 18. Oktober 2019, 10:32:29 CEST schrieb Michael Schroeder:
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
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Oct 18, 2019 at 4:45 AM Fabian Vogt <fvogt@suse.de> wrote:
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. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2019-10-18 10:44, Fabian Vogt wrote:
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 ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019/10/18 08:32:29 +0000, Michael Schroeder wrote:
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:
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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2019-10-18 10:47, Dr. Werner Fink wrote:
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
What condition would need checking? Does the presence of libexec and lib constitute an error in your view? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019/10/18 11:15:40 +0200, Jan Engelhardt wrote:
This is old as well as the mentioned FHS therein, I'm talking about *current* FHS 3 at https://refspecs.linuxfoundation.org/fhs.shtml
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:
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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2019-10-21 10:38, Andreas Schwab wrote:
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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Freitag, 18. Oktober 2019, 10:32:29 CEST schrieb Michael Schroeder:
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 -- <cboltz> are you familiar with git submodules? <sarnold> only to the extent that seem to be a recurring security problem <jjohansen> cboltz: know they exist, but never really used them <jjohansen> and yeah recurring security problem <jjohansen> but that pretty much describes computers [from #apparmor] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Oct 19, 2019 at 4:45 PM Christian Boltz <opensuse@cboltz.de> wrote:
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. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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:
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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2019-11-08 at 10:06 +0100, Bernhard M. Wiedemann wrote:
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:
Why is this still in the distribution, then? Heck, I thought we were using kmod like everyone else already... -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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�����Ǩ�
On Fri, 2019-10-18 at 08:32 +0000, Michael Schroeder wrote:
Thanks for the heads-up. For the record I am fond of the idea. -- 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
Hi, Am Freitag, 18. Oktober 2019, 10:32:29 CEST schrieb Michael Schroeder:
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
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Oct 18, 2019 at 4:45 AM Fabian Vogt <fvogt@suse.de> wrote:
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. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2019-10-18 10:44, Fabian Vogt wrote:
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 ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019/10/18 08:32:29 +0000, Michael Schroeder wrote:
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:
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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (11)
-
Andreas Schwab -
Bernhard M. Wiedemann -
Christian Boltz -
Dr. Werner Fink -
Fabian Vogt -
Jan Engelhardt -
Martin Wilck -
Michael Schroeder -
Neal Gompa -
Richard Brown -
Stasiek Michalski