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. -- 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 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 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-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:

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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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-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 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. -- 真実はいつも一つ！/ 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 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-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 07/11/2019 21.45, Neal Gompa wrote:

On Thu, Nov 7, 2019 at 3:37 PM Martin Wilck 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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Nov 8, 2019 at 4:04 PM Martin Wilck 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... -- 真実はいつも一つ！/ 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