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