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?
From an organizational and project POV I think that's unreasonable. A huge flat
"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 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! -- The master worries about the work, and the apprentice worries about the tools. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org