On Wed, Aug 1, 2012 at 6:11 AM, Linda Walsh
Jan Engelhardt wrote:
On Tuesday 2012-07-31 14:17, Linda Walsh wrote:
I was asking for examples where we do not follow FHS ;-)
By putting 64-bit native programs in the native /usr/lib directory.
As I explained earlier, the most recent version of FHS leave it unspecified where libexec programs should go, and SUSE happened to make the (IMO bad) choice of /usr/lib that is now spurring this discussion, instead of the more reasonable /usr/libexec.
The FHS says they belong in the /lib64 directory
lib64 is for libraries, not programs.
---- Sorry, I sometimes think people can at least figure out what I meant as we were talking libs and progs and /usr/lib(x) /usr/bin(nox) and the idea of making it into /usr(x)/{lib,bin}.
What weight does the FHS carry?...given the many flaws in it's logic and reasoning and the fact that it's nearly a decade out of date.
8 years ago, 64-bit programs were the exception. Today, 64-bit programs are
the Unix standard has libs for /usr/bin in /usr/lib, man pages were in /usr/man, though that was moved to /usr/share/man, as they are often not arch dependent.
The problem comes when you intermix 1 set of programs that are non native in /usr/bin then give the non-native libraries preferential access to.
As for the FHS -- what does it require about the computer as a whole -- I.e. if running in Wine, are programs in /usr/bin and /usr/lib -- I don't think so so.
Then why not have 32-bit libs in /usr/lib when you run a 32-bit program and virtualize it's file access just like Windows did -- or is it that Linux is that much less advanced than Windows?
As for putting things in lib64... Go for it, then when I run 64-bit bash, I'd expect it to see it's libss in /usr/lib, ditto on 1400 other x86-64 packages ...
If the boot package doesn't need 32-bit libs, then what does?...I can toss those 3rd party progs that are for x386 (not even x586) -- they don't work on suse 12.1 anyway.
What prevents putting the 32bit progs and libs in /usr32/{bin+lib} -- which 32-bit progs will see as /usr/{bin,lib} (using same virtualization tech as windows -- or just a linux name space), and map 64-bit progs into /usr64 and back to /usr/{bin,lib}... making room for other options like x86_I64_p32...each could be auto-virtualized to see it's own libraries and bin's where they should be... As for using libexec by default -- if you leave the defaults set to default, don't they go into libexec?
Doesn't someone have to expend effort to change those things?... I mean if code was added in the past to fixate libexec->lib, if the patch were dropped wouldn't that fix things?
FWIW -- suse also has prefix set incorrectly. should be "/" not /usr.
eprefix is for "executable-based stuff" but setting prefix to /usr means several prefixes have to be reset: config dir in /usr/etc has to be be moved to /etc,
things that would work with prefix=/ (and not have to be over-ridden:
sysconfdir (=$prefix/etc) localstatedir=($prefix/var include=($prefix/include) lockdir = ($prefix/$localstatedir/lock) logdir = ($prefix/$localstatedir/log piddir = ($prefix/localstatedir/run/$pkgs
Things that would break well, eprefix would no longer be equal to prefix, but with eprefix set to /usr eprefix based = bin, sbin libexec lib -- the executable things, and libexec for program executables...
People put program executables in /usr/lib? hmmm..... sorta defies logic... but I'm all for as long as those 4 are under the same place, that is fine...
exceptions...executables that don't need libs (statics) can go into /sbin or /bin with /lib being reserved mainly for kernel/driver functions or things in /sbin and /bin that static linkage would create prohibitively large binaries....(you probably don't want libc in every prog...)
but libspecialcase? -- probably should be statically linked...if < 3-7 instances in /bin+/sbin... but that's a off-the-cuff guestimate...
So... aim for native under /usr, BUT really installed in
This is still basically an aesthetic argument. Is there any functional reason to change this? Is there anything that is currently not working that would work better under this scenario? How many packages currently need workaround to install properly that would not need such workarounds under your scenario? -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org