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