[opensuse-packaging] Proposal: Update rpm configuration to fix issues and rationalize configuration
Hello, With some guidance from Michael Schroeder, I'd like to propose a few changes to RPM for Factory / Tumbleweed in time for SLE 15. * Backport the --changes option from RPM git master to rpm 4.13. This is a very simple change that exposes RPM's changelog data with full timestamps. Previously, the commit to support changelogs with full timestamps was backported for reproducible builds work, but the commits for users to access that information easily was not. This is a trivial change, as it merely adds a popt definition and extends the man page to include info on the new parameter. * Change the default binary package payload compression algorithm from old-lzma to xz. Apparently, this change was supposed to have already happened some time ago, but it didn't. This change is simple and brings openSUSE in line with Red Hat Enterprise Linux/CentOS/Fedora and Mageia, as both use xz payloads now. Packages compressed with old-lzma will still be readable by rpm, and even packages compressed with xz will be readable by SLES 12 / OpenSUSE Leap 42 systems. * Define %_sharedstatedir as /var/lib instead of /usr/com. The current path for shared state content (/usr/com) isn't recognized by FHS, whereas /var/lib is recognized as suitable for this purpose, and is currently used as such by Red Hat Enterprise Linux/CentOS/Fedora; Mageia; and Debian/Ubuntu systems. This is expected to be a trivial change, as the /usr/com path has been broken for years and isn't even really used by anything. * Revert %_libexecdir to /usr/libexec. Currently, openSUSE overrides rpm to define %_libexecdir as /usr/lib, which leads to pollution of the /usr/lib directory with executable content as well as 64-bit content when there shouldn't be any. This path has been in use on Red Hat Enterprise Linux/CentOS/Fedora and Mageia systems in the Linux world, but has its origins in BSD and is still used today in BSDs and variants (like Mac OS X). The usage of /usr/libexec for libexec content has also finally been recognized by FHS with v3.0, released in 2015. This is a breaking change, as it means that as packages are rebuilt, libexec content *should* migrate from /usr/lib to /usr/libexec. The major advantage of migrating the libexec content is that it will make openSUSE consistent with other major RPM-based Linux distributions, and ease efforts in supporting SLE/openSUSE Leap/openSUSE Tumbleweed alongside Red Hat/CentOS/Fedora by removing the need for hacks and tweaks to support two different hierarchies. With the exception of the --changes backport, all of these proposed changes are geared towards improving compatibility across RPM-based Linux distributions, particularly the two commercial ones: Red Hat Enterprise Linux and SUSE Linux Enterprise. I believe that by doing this, we can make it easier for people to be encouraged to support SLE/openSUSE as a first class platform alongside Red Hat/CentOS/Fedora for FOSS and commercial software. Best regards, Neal -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 04/24/2017 04:19 PM, Neal Gompa wrote:
Hello,
With some guidance from Michael Schroeder, I'd like to propose a few changes to RPM for Factory / Tumbleweed in time for SLE 15.
* Backport the --changes option from RPM git master to rpm 4.13.
What is the difference to the existing --changelog option? cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Apr 24, 2017 at 10:27 AM, Rüdiger Meier <sweet_f_a@gmx.de> wrote:
On 04/24/2017 04:19 PM, Neal Gompa wrote:
Hello,
With some guidance from Michael Schroeder, I'd like to propose a few changes to RPM for Factory / Tumbleweed in time for SLE 15.
* Backport the --changes option from RPM git master to rpm 4.13.
What is the difference to the existing --changelog option?
The --changes option shows the time as well as the date. --changelog only shows the date. Now that RPM can encode the full timestamp, that's useful information. Upstream wanted it to be a different option rather than updating --changelog, so it is what it is. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2017-04-24 16:19, Neal Gompa wrote:
* Revert %_libexecdir to /usr/libexec. Currently, openSUSE overrides rpm to define %_libexecdir as /usr/lib, which leads to pollution of the /usr/lib directory with executable content as well as 64-bit content when there shouldn't be any.
Notice how systemd uses rootlibexecdir=$(rootprefix)/lib/systemd Since a certain figure associated with the project is working with RedHat, I can't help but think whether maybe SUSE was ahead of its time to consolidate lib and libexec and that systemd copied our idea :-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Apr 24, 2017 at 10:27 AM, Jan Engelhardt <jengelh@inai.de> wrote:
On Monday 2017-04-24 16:19, Neal Gompa wrote:
* Revert %_libexecdir to /usr/libexec. Currently, openSUSE overrides rpm to define %_libexecdir as /usr/lib, which leads to pollution of the /usr/lib directory with executable content as well as 64-bit content when there shouldn't be any.
Notice how systemd uses
rootlibexecdir=$(rootprefix)/lib/systemd
Since a certain figure associated with the project is working with RedHat, I can't help but think whether maybe SUSE was ahead of its time to consolidate lib and libexec and that systemd copied our idea :-)
That was due to Debian wanting the systemd units in the root while not being willing to add /share. Using /lib was the compromise. Systemd is a very strange exception to all of this, because of Debian... :/ -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2017-04-24 16:27, Jan Engelhardt wrote:
On Monday 2017-04-24 16:19, Neal Gompa wrote:
* Revert %_libexecdir to /usr/libexec. Currently, openSUSE overrides rpm to define %_libexecdir as /usr/lib, which leads to pollution of the /usr/lib directory with executable content as well as 64-bit content when there shouldn't be any.
Notice how systemd uses
rootlibexecdir=$(rootprefix)/lib/systemd
Since a certain figure associated with the project is working with RedHat, I can't help but think whether maybe SUSE was ahead of its time to consolidate lib and libexec and that systemd copied our idea :-)
(Trying to imply here that systemd's use of lib over libexec is the beginning of the end of libexec on Fedora..) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Apr 24, 2017 at 10:29 AM, Jan Engelhardt <jengelh@inai.de> wrote:
On Monday 2017-04-24 16:27, Jan Engelhardt wrote:
On Monday 2017-04-24 16:19, Neal Gompa wrote:
* Revert %_libexecdir to /usr/libexec. Currently, openSUSE overrides rpm to define %_libexecdir as /usr/lib, which leads to pollution of the /usr/lib directory with executable content as well as 64-bit content when there shouldn't be any.
Notice how systemd uses
rootlibexecdir=$(rootprefix)/lib/systemd
Since a certain figure associated with the project is working with RedHat, I can't help but think whether maybe SUSE was ahead of its time to consolidate lib and libexec and that systemd copied our idea :-)
(Trying to imply here that systemd's use of lib over libexec is the beginning of the end of libexec on Fedora..)
Incidentally, it was a huge mess to get that change in Fedora, as the units were supposed to be in /usr/share/systemd instead, while the binaries were in /usr/libexec/systemd. The change was made (under protest) because systemd guys wanted the paths to be exactly the same everywhere for systemd units and things. I continue to disagree with this change and I would rather see it fixed at some point, but this is not about the peculiarities of systemd. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Mon, 24 Apr 2017, Neal Gompa wrote:
* Backport the --changes option from RPM git master to rpm 4.13. This * Change the default binary package payload compression algorithm from old-lzma to xz. Apparently, this change was supposed to have already * Define %_sharedstatedir as /var/lib instead of /usr/com. The current
I think all of these are no brainers.
* Revert %_libexecdir to /usr/libexec.
I'd personally like this to happen, yeah. It's in line with the original intent of libexec and lib, and that the FHS didn't recognize it was a long standing bug (IMHO, it certainly was a long-standing annoyance :) ). But it's a change that potentially causes quite some disruption, so do the change in some staging project. If it should happen for SLE-next as well (which I think would be a good thing) then it needs to happen soon. Nevertheless it would be very nice to have this. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Apr 24, 2017 at 12:09 PM, Michael Matz <matz@suse.de> wrote:
Hi,
On Mon, 24 Apr 2017, Neal Gompa wrote:
* Backport the --changes option from RPM git master to rpm 4.13. This * Change the default binary package payload compression algorithm from old-lzma to xz. Apparently, this change was supposed to have already * Define %_sharedstatedir as /var/lib instead of /usr/com. The current
I think all of these are no brainers.
* Revert %_libexecdir to /usr/libexec.
I'd personally like this to happen, yeah. It's in line with the original intent of libexec and lib, and that the FHS didn't recognize it was a long standing bug (IMHO, it certainly was a long-standing annoyance :) ). But it's a change that potentially causes quite some disruption, so do the change in some staging project. If it should happen for SLE-next as well (which I think would be a good thing) then it needs to happen soon. Nevertheless it would be very nice to have this.
I can prepare an SR to Base:System and have it propagate through the normal Factory merge process (that is, the devel->stage->factory release scheme). I believe that should suffice to make sure everything is changed correctly. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Matz schrieb:
On Mon, 24 Apr 2017, Neal Gompa wrote:
* Backport the --changes option from RPM git master to rpm 4.13. This * Change the default binary package payload compression algorithm from old-lzma to xz. Apparently, this change was supposed to have already * Define %_sharedstatedir as /var/lib instead of /usr/com. The current
I think all of these are no brainers.
* Revert %_libexecdir to /usr/libexec.
I'd personally like this to happen, yeah. It's in line with the original intent of libexec and lib, and that the FHS didn't recognize it was a long standing bug (IMHO, it certainly was a long-standing annoyance :) ).
What's wrong with /usr/lib/name/? IMO /usr/libexec is redundant. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
I think /usr/lib suggests 32bit content on x86_64. And also if there is a standard location, why not use it (I am not sure how common libexec is, but if it is widely used then go for it). Regards, Ferdinand Am 25. April 2017 14:27:30 MESZ schrieb
What's wrong with /usr/lib/name/? IMO /usr/libexec is redundant.
cu Ludwig
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 04/25/2017 02:27 PM, Ludwig Nussel wrote:
Michael Matz schrieb:
On Mon, 24 Apr 2017, Neal Gompa wrote:
* Backport the --changes option from RPM git master to rpm 4.13. This * Change the default binary package payload compression algorithm from old-lzma to xz. Apparently, this change was supposed to have already * Define %_sharedstatedir as /var/lib instead of /usr/com. The current
I think all of these are no brainers.
* Revert %_libexecdir to /usr/libexec.
I'd personally like this to happen, yeah. It's in line with the original intent of libexec and lib, and that the FHS didn't recognize it was a long standing bug (IMHO, it certainly was a long-standing annoyance :) ).
What's wrong with /usr/lib/name/? IMO /usr/libexec is redundant.
Isn't $PREFIX/libexec the autoconf default? I've never understood why we don't use $LIBEXEC as expected. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Apr 25, 2017 at 8:38 AM, Rüdiger Meier <sweet_f_a@gmx.de> wrote:
On 04/25/2017 02:27 PM, Ludwig Nussel wrote:
Michael Matz schrieb:
On Mon, 24 Apr 2017, Neal Gompa wrote:
* Backport the --changes option from RPM git master to rpm 4.13. This * Change the default binary package payload compression algorithm from old-lzma to xz. Apparently, this change was supposed to have already * Define %_sharedstatedir as /var/lib instead of /usr/com. The current
I think all of these are no brainers.
* Revert %_libexecdir to /usr/libexec.
I'd personally like this to happen, yeah. It's in line with the original intent of libexec and lib, and that the FHS didn't recognize it was a long standing bug (IMHO, it certainly was a long-standing annoyance :) ).
What's wrong with /usr/lib/name/? IMO /usr/libexec is redundant.
Isn't $PREFIX/libexec the autoconf default? I've never understood why we don't use $LIBEXEC as expected.
It is the default for Autotools, CMake, Meson, and many other build systems that support Unix FHS. I've never understood why the FHS people intentionally ignored the existing usage of /usr/libexec until 2015, but it certainly didn't stop everyone from continuing to use it or set it as default. Only Autotools still does /usr/com by default for @sharedstatedir@, but that's because it supports old Unices. As far as I'm aware, /usr/com dropped out of usage around the time Linux got started, probably because /usr was fully repurposed for read-only data (as opposed to storing user content) by that point and /usr/com was a writable location. Most things moved to using /var/lib because /var *must* be writable and the /var/lib path implies shared variable, persistent content. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Tue, 25 Apr 2017, Ludwig Nussel wrote:
I'd personally like this to happen, yeah. It's in line with the original intent of libexec and lib, and that the FHS didn't recognize it was a long standing bug (IMHO, it certainly was a long-standing annoyance :) ).
What's wrong with /usr/lib/name/?
Everything. lib shall not contain executables. lib shall not contain subdirectories. lib shall contain only libraries. lib shall contain _nothing_ on lib64 platforms.
IMO /usr/libexec is redundant.
20 years of linux distros doing it wrong by overriding perfectly fine autoconf defaults (caused by the FHS not grasping the concept) makes you think so. It is redundant in the same sense that e.g. /usr/include is redundant; let's put everything into /stuff/ . Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Matz schrieb:
Hi,
On Tue, 25 Apr 2017, Ludwig Nussel wrote:
I'd personally like this to happen, yeah. It's in line with the original intent of libexec and lib, and that the FHS didn't recognize it was a long standing bug (IMHO, it certainly was a long-standing annoyance :) ).
What's wrong with /usr/lib/name/?
Everything. lib shall not contain executables. lib shall not contain subdirectories. lib shall contain only libraries. lib shall contain _nothing_ on lib64 platforms.
A pretty radical demand. I guess you have technical insight that makes you say that? Even the dynamic linker may read libraries from subdirectories. Also, what about multilib approaches?
IMO /usr/libexec is redundant.
20 years of linux distros doing it wrong by overriding perfectly fine autoconf defaults (caused by the FHS not grasping the concept) makes you think so.
Perfectly fine defaults like /usr/com? :-) Fedora seems to be rather lonely in the Linux world by using libexec. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, Apr 26, 2017 at 5:21 AM, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Michael Matz schrieb:
Hi,
On Tue, 25 Apr 2017, Ludwig Nussel wrote:
I'd personally like this to happen, yeah. It's in line with the original intent of libexec and lib, and that the FHS didn't recognize it was a long standing bug (IMHO, it certainly was a long-standing annoyance :) ).
What's wrong with /usr/lib/name/?
Everything. lib shall not contain executables. lib shall not contain subdirectories. lib shall contain only libraries. lib shall contain _nothing_ on lib64 platforms.
A pretty radical demand. I guess you have technical insight that makes you say that? Even the dynamic linker may read libraries from subdirectories. Also, what about multilib approaches?
IMO /usr/libexec is redundant.
20 years of linux distros doing it wrong by overriding perfectly fine autoconf defaults (caused by the FHS not grasping the concept) makes you think so.
Perfectly fine defaults like /usr/com? :-) Fedora seems to be rather lonely in the Linux world by using libexec.
Fedora isn't the only one using libexec. Mageia does, and several other offshoots of the Red Hat family do. Slackware and its derivatives do too. There used to be more before FHS blatantly ignored the usage of it for many years. Now that it is recognized by FHS, the offense of having things stuffed into /lib can be eliminated. As for /usr/com, I'm not sure whether it's right or wrong, but for better or worse, Linux systems generally assume /usr can be read-only, so shared state information in /usr is wrong, since that assumes a portion of /usr is always writable. And for what it's worth, only autotools assumes shared state is in /usr/com, everything else assumes /var/lib. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Neal Gompa schrieb:
On Wed, Apr 26, 2017 at 5:21 AM, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Michael Matz schrieb:
On Tue, 25 Apr 2017, Ludwig Nussel wrote:
I'd personally like this to happen, yeah. It's in line with the original intent of libexec and lib, and that the FHS didn't recognize it was a long standing bug (IMHO, it certainly was a long-standing annoyance :) ).
What's wrong with /usr/lib/name/?
Everything. lib shall not contain executables. lib shall not contain subdirectories. lib shall contain only libraries. lib shall contain _nothing_ on lib64 platforms.
A pretty radical demand. I guess you have technical insight that makes you say that? Even the dynamic linker may read libraries from subdirectories. Also, what about multilib approaches?
IMO /usr/libexec is redundant.
20 years of linux distros doing it wrong by overriding perfectly fine autoconf defaults (caused by the FHS not grasping the concept) makes you think so.
Perfectly fine defaults like /usr/com? :-) Fedora seems to be rather lonely in the Linux world by using libexec.
Fedora isn't the only one using libexec. Mageia does, and several other offshoots of the Red Hat family do. Slackware and its derivatives do too.
We're also partially a Slackware descendant but moved away from libexec 20 years ago: $ osc cat openSUSE:Factory gawk gawk.changes|grep -B3 libexec Sun Apr 13 23:04:29 MEST 1997 - florian@suse.de - add bug-fixes from gnu.utils.bugs - do not use /usr/libexec anymore Anyone long enough here to remember why? :-)
There used to be more before FHS blatantly ignored the usage of it for many years. Now that it is recognized by FHS, the
Do we know why it was not part of FHS in the first place? 20 years plain ignorance seems to be a rather simplistic explanation. And why was it changed suddenly? Merely documenting existing practice, accepting that some distros never intended to adopt? Or is there a greater technical vision now (which one?)
offense of having things stuffed into /lib can be eliminated.
I don't feel offended at least :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2017-04-26 14:05, Ludwig Nussel wrote:
There used to be more before FHS blatantly ignored the usage of it for many years. Now that it is recognized by FHS, the
Do we know why it was not part of FHS in the first place?
It feels like I have seen it in FHS before (like, 2.2ish), but all the historic documents still discoverable https://www.ibiblio.org/pub/Linux/docs/fhs/ (2.0 and earlier) socs.acadiau.ca/~jdiamond/Acadia-Linux-template-tutorial/resources/fhs-2.1.pdf http://pathname.com/fhs/ (2.2 and 2.3) turn out not to mention it. However, the Fedora 14, RHEL 3 and RHEL 6 documentation all make it look like it was part of FHS. Maybe that is where I picked up… https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_G... https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/htm... https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm... The libexec thing appears to be inherited from BSD, as it is not documented for Solaris. Given Linux always had a tendency to favor sysv over bsd interfaces, maybe that's why it never got into FHS until 3.0. Of course that's all just conjecture :) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 04/26/2017 02:05 PM, Ludwig Nussel wrote:
Neal Gompa schrieb:
On Wed, Apr 26, 2017 at 5:21 AM, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Michael Matz schrieb:
On Tue, 25 Apr 2017, Ludwig Nussel wrote:
I'd personally like this to happen, yeah. It's in line with the original intent of libexec and lib, and that the FHS didn't recognize it was a long standing bug (IMHO, it certainly was a long-standing annoyance :) ).
What's wrong with /usr/lib/name/?
Everything. lib shall not contain executables. lib shall not contain subdirectories. lib shall contain only libraries. lib shall contain _nothing_ on lib64 platforms.
A pretty radical demand. I guess you have technical insight that makes you say that? Even the dynamic linker may read libraries from subdirectories. Also, what about multilib approaches?
IMO /usr/libexec is redundant.
20 years of linux distros doing it wrong by overriding perfectly fine autoconf defaults (caused by the FHS not grasping the concept) makes you think so.
Perfectly fine defaults like /usr/com? :-) Fedora seems to be rather lonely in the Linux world by using libexec.
Fedora isn't the only one using libexec. Mageia does, and several other offshoots of the Red Hat family do. Slackware and its derivatives do too.
We're also partially a Slackware descendant but moved away from libexec 20 years ago:
$ osc cat openSUSE:Factory gawk gawk.changes|grep -B3 libexec Sun Apr 13 23:04:29 MEST 1997 - florian@suse.de
- add bug-fixes from gnu.utils.bugs - do not use /usr/libexec anymore
Anyone long enough here to remember why? :-)
I guess there is very simple explanation. Seem's like gawk is using "libexecdir" since gawk-3.0. That was around 1996/97. In the autoconf documentation "libexecdir" was firstly mentioned around 1994, August (maybe released even later). So I guess that at this time (1995-1997) first projects slowly started actually using "libexecdir". From the view of a user or distro developer it was probably like: "WTF, why gawk suddenly introduces such stupid /usr/libexec. We don't need it. We don't want it. We don't use this!" Hehe, this issue reminds me a bit about the monkey/ladder experiment https://i.stack.imgur.com/MyQki.jpg
There used to be more before FHS blatantly ignored the usage of it for many years. Now that it is recognized by FHS, the
Do we know why it was not part of FHS in the first place? 20 years plain ignorance seems to be a rather simplistic explanation. And why was it changed suddenly? Merely documenting existing practice, accepting that some distros never intended to adopt? Or is there a greater technical vision now (which one?)
Yes, I guess just because major distros never used it. If they wouldn't have followed freedesktop/systemd then FHS would also look different. cu, Rudi
offense of having things stuffed into /lib can be eliminated.
I don't feel offended at least :-)
cu Ludwig
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, Apr 26, Neal Gompa wrote:
As for /usr/com, I'm not sure whether it's right or wrong, but for better or worse, Linux systems generally assume /usr can be read-only,
Which is not correct. FHS says /usr can be read-only, but most Linux systems cannot scope with that and will report errors. Only because FHS demands it does not mean developers will take care of it... And yes, as I'm currently working on a system with root read-only, I know about what I'm speaking. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Wed, 26 Apr 2017, Ludwig Nussel wrote:
What's wrong with /usr/lib/name/?
Everything. lib shall not contain executables. lib shall not contain subdirectories. lib shall contain only libraries. lib shall contain _nothing_ on lib64 platforms.
A pretty radical demand. I guess you have technical insight that makes you say that?
From there it follows fairly easily that /usr/lib should be empty on a
It's not so much technical, but as I said there are also no technical reasons why e.g. /usr/include would be separate, all its content could just as well be stuffed into /usr/lib. It's about what conceptually belongs where, header files to /usr/include, libraries to /usr/lib and executables called only internally by other tools into /usr/libexec, or /usr/libexec/$toolname (modules would belong into this category) and other files associated with a tool into /usr/share. pure lib64 system. Also /usr/lib should be able to be mounted noexec, and everything should continue to work. One advantage of putting executable helpers for a tool into libexec, not lib{,64} would be that the path doesn't depend on architecture bits (as it should be, because for executables the bitness doesn't matter, for libraries it does).
Even the dynamic linker may read libraries from subdirectories.
Only if configured in /etc/ld.so.conf or LD_LIBRARY_PATH.
Also, what about multilib approaches?
What about them? They're orthogonal to libexec (except in so far as cleaning up cruft from lib makes multilib approaches easier). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Matz schrieb:
On Wed, 26 Apr 2017, Ludwig Nussel wrote:
What's wrong with /usr/lib/name/?
Everything. lib shall not contain executables. lib shall not contain subdirectories. lib shall contain only libraries. lib shall contain _nothing_ on lib64 platforms.
A pretty radical demand. I guess you have technical insight that makes you say that?
It's not so much technical, but as I said there are also no technical reasons why e.g. /usr/include would be separate, all its content could just as well be stuffed into /usr/lib. It's about what conceptually
/usr/include is rather special as it's really only for C. All others have to live with a subdir in /usr/share or - /usr/lib.
belongs where, header files to /usr/include, libraries to /usr/lib and executables called only internally by other tools into /usr/libexec, or /usr/libexec/$toolname (modules would belong into this category) and other files associated with a tool into /usr/share.
From there it follows fairly easily that /usr/lib should be empty on a pure lib64 system. Also /usr/lib should be able to be mounted noexec, and
So where would you move /usr/lib/perl5 then? I has it's own architecture specific subdirectories. And where to put plugins in general? They ought to be in subdirectories of lib to not interfere with the dynamic linker.
everything should continue to work. One advantage of putting executable helpers for a tool into libexec, not lib{,64} would be that the path doesn't depend on architecture bits (as it should be, because for executables the bitness doesn't matter, for libraries it does).
Packages that put helper binaries in lib64 are doing it wrong unless the binary has an ABI incompatible with a 32bit library that calls it. On a system without libexec, /usr/lib/%name is the right choice rather than %_libdir/%name.
Even the dynamic linker may read libraries from subdirectories.
Only if configured in /etc/ld.so.conf or LD_LIBRARY_PATH.
It looks into e.g. tls and x86_64 subdirectories on x86_64 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Wed, 26 Apr 2017, Ludwig Nussel wrote:
belongs where, header files to /usr/include, libraries to /usr/lib and executables called only internally by other tools into /usr/libexec, or /usr/libexec/$toolname (modules would belong into this category) and other files associated with a tool into /usr/share.
From there it follows fairly easily that /usr/lib should be empty on a pure lib64 system. Also /usr/lib should be able to be mounted noexec, and
So where would you move /usr/lib/perl5 then? I has it's own architecture specific subdirectories. And where to put plugins in general? They ought to be in subdirectories of lib to not interfere with the dynamic linker.
As I said, modules (i.e. DSOs that are used with dlopen, not loaded by ld.so) would be placed into (subdirs of) libexec (conceptually (to me) they are more similar to helper executables than shared libraries; they just happen to be implemented via shared library mechanisms) /usr/lib/perl5 is one of the big blobs with its own way of doing things. Many (but not all) of the files therein are not arch dependend or binary, and hence would actually have a better place under /usr/share. The binary files that are there are not shared libraries for the dynamic loader but dlopen modules, so that would speak for libexec. Splitting the content of perl stuff between /usr/share and /usr/libexec might be seen as to large a hassle (though with the appropriate setting of $PERL5LIB might be invisible in practice), or going against perls idea that there should be "the" main directory for putting stuff in (though even that would be wrong to claim, perl is happy when confired with additional search dirs). So, considering this I'd answer you with "/usr/libexec/perl5", or "split into /usr/libexec/perl5 and /usr/share/perl5".
everything should continue to work. One advantage of putting executable helpers for a tool into libexec, not lib{,64} would be that the path doesn't depend on architecture bits (as it should be, because for executables the bitness doesn't matter, for libraries it does).
Packages that put helper binaries in lib64 are doing it wrong unless the binary has an ABI incompatible with a 32bit library that calls it.
Huh? No, whatever the bitness of executable-a (and hence libs used by it), that doesn't at all have to influence the bitness of exe-b execve(2)'ed by it. So, it's _always_ wrong to put executables into lib64 (and I agree with that if libexec isn't used). Nevertheless it happens, and I claim it happens because if a tool has shared libs and helper exes the packager is confused what to place where and just chooses lib64 for everything, and I further claim that with libexec with the appropriate role (or better with lib/lib64 having very strict roles) there would be less confusion. (The rule then would be very easy: every shared lib that's directly shown in output of ldd is put into lib{,64}, and _everything else_ is not put there).
On a system without libexec, /usr/lib/%name is the right choice rather than %_libdir/%name.
Yes, agreed as per above. I just randomly looked at gawk for other reasons, et voila, it already gets that part wrong.
Even the dynamic linker may read libraries from subdirectories.
Only if configured in /etc/ld.so.conf or LD_LIBRARY_PATH.
It looks into e.g. tls and x86_64 subdirectories on x86_64
Yes, so? Those directories also contain shared libraries, and hence it's fine for them to be under lib. Do you mean the discrepancy with my request that lib shall not contain subdirs? To be honest I indeed forgot about these subdirs, but they are an artifact of the ld.so implementation trying to support hardware dependend libs. They never were used much, are hardcoded by ld.so (so that particular set is not extensible) and since the introduction of indirect functions should (and are going to) be replaced by that. So I don't consider them regular subdirs of lib, but rather a funny way of prefixing library names. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2017-04-26 17:57, Michael Matz wrote:
From there it follows fairly easily that /usr/lib should be empty on a pure lib64 system. Also /usr/lib should be able to be mounted noexec, and
So where would you move /usr/lib/perl5 then? I has it's own architecture specific subdirectories. And where to put plugins in general? They ought to be in subdirectories of lib to not interfere with the dynamic linker.
As I said, modules (i.e. DSOs that are used with dlopen, not loaded by ld.so) would be placed into (subdirs of) libexec (conceptually (to me) they are more similar to helper executables than shared libraries; they just happen to be implemented via shared library mechanisms)
/usr/lib/perl5 is one of the big blobs with its own way of doing things. Many (but not all) of the files therein are not arch dependend or binary, and hence would actually have a better place under /usr/share. The binary files that are there are not shared libraries for the dynamic loader but dlopen modules, so that would speak for libexec.
It's not that easy. perl also exists as a dynamic loader library (libperl.so) that could exist in multiple bitnesses, which means all the Perl modules (well,mthe XS things) cannot be libexec aka single bitness. Same for Python.. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Wed, 26 Apr 2017, Jan Engelhardt wrote:
/usr/lib/perl5 is one of the big blobs with its own way of doing things. Many (but not all) of the files therein are not arch dependend or binary, and hence would actually have a better place under /usr/share. The binary files that are there are not shared libraries for the dynamic loader but dlopen modules, so that would speak for libexec.
It's not that easy. perl also exists as a dynamic loader library (libperl.so) that could exist in multiple bitnesses, which means all the Perl modules (well,mthe XS things) cannot be libexec aka single bitness.
That should be taken care of by the arch-dependend mechanism that perl already has: % echo $PERL5LIB /suse/matz/perl5/lib/perl5:/suse/matz/perl5/lib/perl5:/suse/matz/perl5/lib/perl5 % perl -V ... /suse/matz/perl5/lib/perl5/x86_64-linux-thread-multi /suse/matz/perl5/lib/perl5 ... /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.2 So, libperl.so goes into lib{,64} the modules and header wrappers (if arch dependend) into the libexec/perl5/$triplet directories. python could probably be made to do similar things. Now, having said this, in might very well be that perl turns out to be in the "ah, crap, too much work, ignore it" category and remains an exception, even if we otherwise would follow a changed policy of having libexec. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Matz schrieb:
On Wed, 26 Apr 2017, Ludwig Nussel wrote:
belongs where, header files to /usr/include, libraries to /usr/lib and executables called only internally by other tools into /usr/libexec, or /usr/libexec/$toolname (modules would belong into this category) and other files associated with a tool into /usr/share.
From there it follows fairly easily that /usr/lib should be empty on a pure lib64 system. Also /usr/lib should be able to be mounted noexec, and
So where would you move /usr/lib/perl5 then? I has it's own architecture specific subdirectories. And where to put plugins in general? They ought to be in subdirectories of lib to not interfere with the dynamic linker.
As I said, modules (i.e. DSOs that are used with dlopen, not loaded by ld.so) would be placed into (subdirs of) libexec (conceptually (to me) they are more similar to helper executables than shared libraries; they just happen to be implemented via shared library mechanisms)
Shared libraries need to have matching architecures though. Ie 32bit and 64bit libs need different plugins (like e.g. pam modules). So putting them in libexec wouldn't work.
[...] Packages that put helper binaries in lib64 are doing it wrong unless the binary has an ABI incompatible with a 32bit library that calls it.
Huh? No, whatever the bitness of executable-a (and hence libs used by it), that doesn't at all have to influence the bitness of exe-b execve(2)'ed by it. So, it's _always_ wrong to put executables into lib64
In theory a binary could speak a protocol with it's calling library that differs depending on architecture (like eg. writing structs in shared memory). In such a case it would have to go to lib64.
/usr/lib/perl5 is one of the big blobs with its own way of doing things. Many (but not all) of the files therein are not arch dependend or binary, and hence would actually have a better place under /usr/share. The binary files that are there are not shared libraries for the dynamic loader but dlopen modules, so that would speak for libexec. Splitting the content of perl stuff between /usr/share and /usr/libexec might be seen as to large a hassle (though with the appropriate setting of $PERL5LIB might be invisible in practice), or going against perls idea that there should be "the" main directory for putting stuff in (though even that would be wrong to claim, perl is happy when confired with additional search dirs).
So, considering this I'd answer you with "/usr/libexec/perl5", or "split into /usr/libexec/perl5 and /usr/share/perl5".
Sounds like libexec would lead to even more hairsplitting about where files should be placed for little if any at all practical benefit.
(and I agree with that if libexec isn't used). Nevertheless it happens, and I claim it happens because if a tool has shared libs and helper exes the packager is confused what to place where and just chooses lib64 for everything, and I further claim that with libexec with the appropriate role (or better with lib/lib64 having very strict roles) there would be less confusion. (The rule then would be very easy: every shared lib that's directly shown in output of ldd is put into lib{,64}, and _everything else_ is not put there).
On a system without libexec, /usr/lib/%name is the right choice rather than %_libdir/%name.
Yes, agreed as per above. I just randomly looked at gawk for other reasons, et voila, it already gets that part wrong.
It wrongly uses --libexecdir=%{_libdir}. Doesn't matter how we define %_libexecdir then :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 2017-04-26 at 17:57 +0200, Michael Matz wrote:
As I said, modules (i.e. DSOs that are used with dlopen, not loaded by ld.so) would be placed into (subdirs of) libexec (conceptually (to me) they are more similar to helper executables than shared libraries; they just happen to be implemented via shared library mechanisms)
Let's take a very practical example, showing that this can't work: e.g libproxy (the library) and any of it's modules e.g. libproxy- config- The lib is obviously in /usr/lib64/libproxy.so.1 the config module to it (arch dependent, loaded dynamically) in /usr/lib64/libproxy-%{version}/modules/config-gnome3.so libproxy being used by quite some low-level things is also provided as biarch, so we have libproxy1-32bit (/usr/lib/libproxy.so.1) the 23bit variant on a 64bit system obviously needs to find it's modules in a path that are not equal to the 64bit variant. Putting that stuff into libexec sounds totally weird and would just require to split stuff up even weirder... => modules loaded by a lib belong in my opinion to %{_libdir}/%{name} Cheers, Dominique
On Wed, May 24, 2017 at 3:35 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Wed, 2017-04-26 at 17:57 +0200, Michael Matz wrote:
As I said, modules (i.e. DSOs that are used with dlopen, not loaded by ld.so) would be placed into (subdirs of) libexec (conceptually (to me) they are more similar to helper executables than shared libraries; they just happen to be implemented via shared library mechanisms)
Let's take a very practical example, showing that this can't work:
e.g libproxy (the library) and any of it's modules e.g. libproxy- config-
The lib is obviously in /usr/lib64/libproxy.so.1 the config module to it (arch dependent, loaded dynamically) in /usr/lib64/libproxy-%{version}/modules/config-gnome3.so
libproxy being used by quite some low-level things is also provided as biarch, so we have libproxy1-32bit (/usr/lib/libproxy.so.1)
the 23bit variant on a 64bit system obviously needs to find it's modules in a path that are not equal to the 64bit variant.
Putting that stuff into libexec sounds totally weird and would just require to split stuff up even weirder...
=> modules loaded by a lib belong in my opinion to %{_libdir}/%{name}
I don't disagree with that. If it's a dylib/so file, then it belongs in the private directory under %_libdir, especially if it's being loaded by a library. libexec is for helper programs only. That is, programs that are executed by other programs but should never be run by users. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2017-04-26 17:12, Ludwig Nussel wrote:
/usr/include is rather special as it's really only for C. All others have to live with a subdir in /usr/share or - /usr/lib.
/ That ship has already sailed. Projects are starting to use $includedir for.. things. Some 30000 files exist in factory in $include that don't end in typical C andnC++ filenames. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Wed, 26 Apr 2017, Jan Engelhardt wrote:
/usr/include is rather special as it's really only for C. All others have to live with a subdir in /usr/share or - /usr/lib.
That ship has already sailed. Projects are starting to use $includedir for.. things. Some 30000 files exist in factory in $include that don't end in typical C andnC++ filenames.
Sigh. Is it just me or is everything really going downhill? :-) Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (8)
-
Dominique Leuenberger / DimStar -
Ferdinand Thiessen -
Jan Engelhardt -
Ludwig Nussel -
Michael Matz -
Neal Gompa -
Rüdiger Meier -
Thorsten Kukuk