[opensuse-factory] Re: [opensuse-packaging] Proposal: Update rpm configuration to fix issues and rationalize configuration
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
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.
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
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 :)
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
On 26/04/17 05:21 AM, Ludwig Nussel 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.
Indeed!
I guess you have technical insight that makes you say that?
"Technical"? Isn't this about organization? Isn't this akin to the Great /etc Repatriation Project of some years ago?
Let's see
* No executables
Well, that seems reasonable. /{usr/,}lib isn't on the $PATH LD_LIBRARY_PATH is quite another matter.
* No subdirectories
From an organizational and project POV I think that's unreasonable. A huge flat
directory beings into the matter of search times with some file systems.
There are some projects, X11 is a good illustration, where there is only sharing within the project, and grouping to libraries for that project makes sense.
But lets not get obsessive. MS-Windows takes this to an extreme where the is woefully inadequate cross project sharing and hence an incredible amount of code duplication. In addition, each 'project' has its own subdirectory where all the code and data lives.
* Empty "lib" on 64-bit systems
I think this is the wrong way round.
On 16-bit systems we have /{usr/,}lib where the 16-bit library code lived On 32-bit systems we have /{usr/,}lib where the 32-bit library code lived
Why are 64-bit systems different? Why do we have /{usr/,}lb64 for the 64-bit code?
Why doesn't the 64-bit code line in /{usr/,}lib and the 32-bit code live in /{lib,}32 ??
After all, we don't have /{usr/,}bin64
The history of UNIX and Linux (and USENET and the Internet) is littered with the build-up of fluff until it starts to get in the way and then there is a burst of rationalization.
Maybe one day the naming authority will decide that 'DOT COM' is overloaded and forcibly move accounts, depending on how they are incorporated, out to, for example DOT LTD and DOT INC.
Yea, right! Dream on!
-
Anton Aylward -
Jan Engelhardt -
Ludwig Nussel -
Neal Gompa -
Rüdiger Meier