Hi, (collecting all replies here) Am Donnerstag, 27. August 2020, 12:45:39 CEST schrieb Neal Gompa:
Debian switched %_libexecdir to /usr/libexec when they upgraded to FHS 3.0 in 2018. This change is particularly evident in gnome-terminal, which now installs binaries there. They are (slowly) removing their hacks around libexecdir in the distribution so that stuff goes in /usr/libexec again.
Looks like they didn't get too far yet, I checked by looking into the debian:10 image from the docker library and there is no libexec anywhere. How are they performing the move in a slow manner compared to Tumbleweed ripping off like a band-aid? Am Donnerstag, 27. August 2020, 16:30:09 CEST schrieb Jan Engelhardt:
On Thursday 2020-08-27 09:39, Fabian Vogt wrote:
At this point I really wonder whether this change is necessary and worth it. FWICT, the reasoning for this change is twofold: a) It aligns with the FHS b) It aligns with other distros
About a), the FHS actually says that /usr/lib is also acceptable: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
c) It aligns with some other OSes, too. (FreeBSD)
Even macOS appears to use /usr/libexec, fair enough.
d) It aligns with upstream's standard installation layout. As in, autoconf (and others) have had a --libexecdir flag.
Just because it is possible for a builder to override the plethora of setting offered does not mean it is always necessary to do so.
Everything already works with the current setup, so adding more points on top of the "blend in" heap doesn't really put any more weight on that IMO.
Documentation and bugreports favorable mention /usr/libexec. But, whenever SUSE is involved, involved people need a mental hook that it's /usr/lib instead, and they'll go like <Ryan Reynolds: "... but why?">
Debian has /usr/<triple>/ and gets the same reaction from me. Though that directory structure actually provides some (small) benefit, compared to /usr/libexec.
On top of those two reasons, I'm not aware of any immediate issue or problem it fixes, compared to e.g. the /usr/etc movement. So this change appears to be entirely cosmetic.
Quite so. But changing from libexec to lib to please ye olde FHS2.3 some 20ish years ago, that itself was already a cosmetic change (and not one with much value; see a-d). We're just removing the makeup now.
The makeup is already part of the skin now, it looks fine and everyone got used to it. Forcibly removing it *will* hurt, everyone has to get used to it again and after it has healed it'll look at best the same. Am Donnerstag, 27. August 2020, 16:49:52 CEST schrieb Callum Farmer:
e) We move back but we still have misuses of the macro
I agree that cleaning up misuse of macros is good, but it shouldn't hurt users, just to make some .spec files and macros a tiny bit simpler.
f) executables in a directory that should be for shared libraries (to match /usr/lib64). FHS 3.0 only says to allow /usr/lib aswell for historical purposes aka FHS 2.3.
Where does it say that? It says that it's acceptable precisely because /usr/lib is already widely used. Cheers, Fabian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org