[opensuse-factory] TW 0825: %{_libexecdir} == /usr/libexec
Dear Tumbleweed users and hackers, After a few months of hard labor by many package maintainers, we reached the point where we could merge the change for %_libexecdir now. Snapshot 0825 has just started building and will be the first snapshot to come out (or to be built - we'll see if it will be published) with that change enabled. As this is a change also having impact on interactions between packages it was nescessary to trigger a rebuild of all packages. It's not realistically possible to identify the packages that would effectively be affected. So, besides the 'big change', you can expect also 'big download' for Snapshot 0825 (or the first snapshot to be published after that date). Please be extra attentive to things no longer behaving as you expect. There is unfortunately a chance that some packages have hardcoded paths to files that moved around or also packages that hardcoded the install path even though things expect the helpers in different locations. Should you come across one of your packages failing to build, it would be appreciated by all users of said package to receive a fix rather sooner than later. Than kyou all for your great work on this topic. It once again showed that together, we can reach even such larger goals and doing so without rishing things. Cheers, Dominique
On Tuesday 2020-08-25 10:32, Dominique Leuenberger / DimStar wrote:
Dear Tumbleweed users and hackers,
After a few months of hard labor by many package maintainers, we reached the point where we could merge the change for %_libexecdir now.
One issue of note is that users who modified sshd_config should now be getting a sshd_config.rpmnew, /etc/ssh/sshd_config:Subsystem sftp /usr/lib/ssh/sftp-server /etc/ssh/sshd_config.rpmnew:Subsystem sftp /usr/libexec/ssh/sftp-server if left unfixed, sftp will be effectively nonfunctional. # sftp localhost Connection closed. Connection closed -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-08-25 at 10:56 +0200, Jan Engelhardt wrote:
On Tuesday 2020-08-25 10:32, Dominique Leuenberger / DimStar wrote:
Dear Tumbleweed users and hackers,
After a few months of hard labor by many package maintainers, we reached the point where we could merge the change for %_libexecdir now.
One issue of note is that users who modified sshd_config should now be getting a sshd_config.rpmnew,
/etc/ssh/sshd_config:Subsystem sftp /usr/lib/ssh/sftp-server /etc/ssh/sshd_config.rpmnew:Subsystem sftp /usr/libexec/ssh/sftp-server
if left unfixed, sftp will be effectively nonfunctional.
# sftp localhost Connection closed. Connection closed
Thanks for that headsup - there will likely be more such cases. whenever rpm creates .rpmnew/.rpmsave files, it's important to verify the differences. Cheers, Dominique
Am 25.08.20 um 10:32 schrieb Dominique Leuenberger / DimStar:
Dear Tumbleweed users and hackers,
After a few months of hard labor by many package maintainers, we reached the point where we could merge the change for %_libexecdir now.
In llvm, we're currently moving some files from /usr/libexec to /usr/bin as a leftover from earlier times: mv %{buildroot}%{_prefix}/libexec/{c++,ccc}-analyzer \ %{buildroot}%{_bindir} Now I would like to change that, but older distros still have %{_libexecdir} == /usr/lib and the executable is expected in either /usr/libexec or /usr/bin. Any advice on this? My idea would be to branch on %{_libexecdir} == /usr/libexec and fall back to %{_bindir} if that isn't satisfied. Best regards, Aaron -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2020-08-25 22:33, Aaron Puchert wrote:
Am 25.08.20 um 10:32 schrieb Dominique Leuenberger / DimStar:
Dear Tumbleweed users and hackers,
After a few months of hard labor by many package maintainers, we reached the point where we could merge the change for %_libexecdir now.
In llvm, we're currently moving some files from /usr/libexec to /usr/bin as a leftover from earlier times:
mv %{buildroot}%{_prefix}/libexec/{c++,ccc}-analyzer \ %{buildroot}%{_bindir}
Now I would like to change that, but older distros still have %{_libexecdir} == /usr/lib and the executable is expected in either /usr/libexec or /usr/bin. Any advice on this?
%install ... if ! test -e %buildroot/%bindir/ccc-analyzer; then ln -s %_libexecdir/ccc-analyzer %buildroot/%bindir/ccc-analyzer fi ... It does not hurts to have a symlink too much. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 25.08.20 um 22:54 schrieb Jan Engelhardt:
%install ... if ! test -e %buildroot/%bindir/ccc-analyzer; then ln -s %_libexecdir/ccc-analyzer %buildroot/%bindir/ccc-analyzer fi ...
It does not hurts to have a symlink too much.
Hmm, but isn't the idea behind /usr/libexec to have the executables not in $PATH, because they are not meant to be invoked by users? These two are only used internally by scan-build, which looks for them first in /usr/libexec, then /usr/bin: # Determine the location of ccc-analyzer. my $AbsRealBin = Cwd::realpath($RealBin); my $Cmd = "$AbsRealBin/../libexec/ccc-analyzer"; # ... if (!defined $Cmd || ! -e $Cmd) { $Cmd = "$AbsRealBin/ccc-analyzer"; DieDiag("'ccc-analyzer' does not exist at '$Cmd'\n") if(! -e $Cmd); } # ... So if it's in /usr/libexec, it doesn't need to be in /usr/bin. But for older distros (currently everything != Tumbleweed) I want to keep them in /usr/bin since /usr/libexec doesn't exist and %{_libexecdir} == /usr/lib, where the script doesn't look. Best regards, Aaron -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Aug 25, Aaron Puchert wrote:
Am 25.08.20 um 22:54 schrieb Jan Engelhardt:
%install ... if ! test -e %buildroot/%bindir/ccc-analyzer; then ln -s %_libexecdir/ccc-analyzer %buildroot/%bindir/ccc-analyzer fi ...
It does not hurts to have a symlink too much.
Hmm, but isn't the idea behind /usr/libexec to have the executables not in $PATH, because they are not meant to be invoked by users?
Correct, having them in bin and libexec doesn't make much sense. I would check if /usr/libexec exists, if yes, use it, else /usr/bin. Thorsten
These two are only used internally by scan-build, which looks for them first in /usr/libexec, then /usr/bin:
# Determine the location of ccc-analyzer. my $AbsRealBin = Cwd::realpath($RealBin); my $Cmd = "$AbsRealBin/../libexec/ccc-analyzer"; # ... if (!defined $Cmd || ! -e $Cmd) { $Cmd = "$AbsRealBin/ccc-analyzer"; DieDiag("'ccc-analyzer' does not exist at '$Cmd'\n") if(! -e $Cmd); } # ...
So if it's in /usr/libexec, it doesn't need to be in /usr/bin. But for older distros (currently everything != Tumbleweed) I want to keep them in /usr/bin since /usr/libexec doesn't exist and %{_libexecdir} == /usr/lib, where the script doesn't look.
Best regards, Aaron -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am Dienstag, 25. August 2020, 10:32:00 CEST schrieb Dominique Leuenberger / DimStar:
Dear Tumbleweed users and hackers,
After a few months of hard labor by many package maintainers, we reached the point where we could merge the change for %_libexecdir now.
Snapshot 0825 has just started building and will be the first snapshot to come out (or to be built - we'll see if it will be published) with that change enabled.
As this is a change also having impact on interactions between packages it was nescessary to trigger a rebuild of all packages. It's not realistically possible to identify the packages that would effectively be affected. So, besides the 'big change', you can expect also 'big download' for Snapshot 0825 (or the first snapshot to be published after that date).
Please be extra attentive to things no longer behaving as you expect. There is unfortunately a chance that some packages have hardcoded paths to files that moved around or also packages that hardcoded the install path even though things expect the helpers in different locations.
I realize I'm a bit late to the discussion here, but when this topic came up initially I wasn't familiar enough with the facts to actually respond. 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
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.
It's not entirely clear to me how that is exactly meant. My interpretation is that if /usr/libexec is provided, it is preferred over /usr/lib, but it is not mandatory. That means Tumbleweed is in the clear already. About b), it just changes the list of distros it aligns with: Arch and Debian-based use %_libexecdir == %_libdir while Fedora and Slackware use %_libexecdir != %_libdir, i.e. /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. The warning in the quoted mail is quite severe, but it's really true. The current openQA results show that both chromium and man are completely broken. Those issues will be fixed, but that's just the visible tip of the iceberg. There are many more cases not covered by build-testing and openQA, which will keep surfacing even in the further away future, as subtle breakage appears, something like AppArmor denying access to some less frequently used program. All of that really makes me wonder whether this change is actually worth doing, as there aren't any immediate benefits and it causes severe breakage. Unless I'm missing something (please enlighten me in that case!), I propose to change back to the old value of %_libexec. Cheers, Fabian
Should you come across one of your packages failing to build, it would be appreciated by all users of said package to receive a fix rather sooner than later.
Than kyou all for your great work on this topic. It once again showed that together, we can reach even such larger goals and doing so without rishing things.
Cheers, Dominique
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Aug 27, 2020 at 3:45 AM Fabian Vogt <fvogt@suse.de> wrote:
Hi,
Am Dienstag, 25. August 2020, 10:32:00 CEST schrieb Dominique Leuenberger / DimStar:
Dear Tumbleweed users and hackers,
After a few months of hard labor by many package maintainers, we reached the point where we could merge the change for %_libexecdir now.
Snapshot 0825 has just started building and will be the first snapshot to come out (or to be built - we'll see if it will be published) with that change enabled.
As this is a change also having impact on interactions between packages it was nescessary to trigger a rebuild of all packages. It's not realistically possible to identify the packages that would effectively be affected. So, besides the 'big change', you can expect also 'big download' for Snapshot 0825 (or the first snapshot to be published after that date).
Please be extra attentive to things no longer behaving as you expect. There is unfortunately a chance that some packages have hardcoded paths to files that moved around or also packages that hardcoded the install path even though things expect the helpers in different locations.
I realize I'm a bit late to the discussion here, but when this topic came up initially I wasn't familiar enough with the facts to actually respond.
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
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.
It's not entirely clear to me how that is exactly meant. My interpretation is that if /usr/libexec is provided, it is preferred over /usr/lib, but it is not mandatory. That means Tumbleweed is in the clear already.
About b), it just changes the list of distros it aligns with: Arch and Debian-based use %_libexecdir == %_libdir while Fedora and Slackware use %_libexecdir != %_libdir, i.e. /usr/libexec.
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. -- 真実はいつも一つ！/ 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 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) 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. 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?">
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
On Fri, Aug 28, 2020 at 10:45 AM Fabian Vogt <fvogt@suse.de> wrote:
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?
Well, they don't do mass rebuilds on a regular basis, so stuff churns over when packages are updated. :) The first one to make the change was the GNOME stack. I expect that we'll see more of it as we get closer to Debian 11's release. The changes in the GNOME stack did make it into Ubuntu 20.04, though. -- 真実はいつも一つ！/ 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
* Dominique Leuenberger / DimStar <dimstar@opensuse.org> [08-25-20 04:33]:
Dear Tumbleweed users and hackers,
After a few months of hard labor by many package maintainers, we reached the point where we could merge the change for %_libexecdir now.
Snapshot 0825 has just started building and will be the first snapshot to come out (or to be built - we'll see if it will be published) with that change enabled.
this change included moving /usr/lib/mc to /usr/libexec/mc and automagically altered the included config files, but failed to alter <user> files such as ~/.config/mc/mc.exe. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (7)
-
Aaron Puchert -
Dominique Leuenberger / DimStar -
Fabian Vogt -
Jan Engelhardt -
Neal Gompa -
Patrick Shanahan -
Thorsten Kukuk