Re: [opensuse-factory] Re: [opensuse] Re: Why bin & no bin64? => lets fix lib64=>lib, bin(32),lib(32)=>/usr32/{bin,lib}
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 /usr-arch with link or virtualize to /usr? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Could you stop needlessly crossposting to both opensuse and
opensuse-factory? Thank you.
On Tue, 31 Jul 2012 21:11:39 -0700, Linda Walsh
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?
Linux isn't Windows, where MS only choice was the virtualization in order to satisfy the needs of all those closed source programs out there. In Linux we have acess to the source code so we can, for the most part, change the placeses where things are accepted to reside.
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 ...
*You* would expect that, the majority of users won't, I bet you. As long as the dynamic linker finds the needed libraries, no user will bother with where they reside.
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)
W 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)
Wrong! System wide include directory is /usr/include, not /include.
People put program executables in /usr/lib?
Not people, it's the definition of libexecdir that bits us here as Anders has told you more than once.
but libspecialcase? -- probably should be statically linked...if < 3-7 instances in /bin+/sbin... but that's a off-the-cuff guestimate...
Nope, from a security and maintenance POV you'd rather want dynamic libraries only.
So... aim for native under /usr, BUT really installed in /usr-arch with link or virtualize to /usr?
Why use resource eating virtualization when you can work without it? Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Linda Walsh -
Philipp Thomas