August 2012 - openSUSE Users - openSUSE Mailing Lists

[opensuse] Re: Why bin & no bin64? => lets fix lib64=>lib, bin(32),lib(32)=>/usr32/{bin,lib}
by Linda Walsh 02 Aug '12

02 Aug '12

Nelson Marques wrote: > Ever heard of FHS? It's stands for Filesystem Hierarchy Standard. > > Enjoy the reading :) ---- It is based on really screwed up reasoning. Why was it accepted? Regardless, Suse doesn't follow it now, so why not move ahead with a more soundly reasoned solution. Seems a smart solution would be to use a separate file-system namespace with everything but the bin & lib directories being the same between 32&64 bit. Would provid transparency. Their rational .. that lib(X) is architecture dependent, also applies to /bin, yet they don't apply the same reasoning. ... more specifically under specific options, they also say: lib<qual> Alternate format essential shared libraries (optional) "Lib<qual>" is for an alternate format. Alternate to what? I would assert alternate format doesn't mean native format. And that on a X64 machine running an X64 kernel where x32 compatibility is *optional*, that it is 32-bit dirs that are optional. So the document is internally inconsistent besides being. ========= I think having a smart loader that virtualizes the arch-dependent dirs. To make it arch, blind, create a /usr64/{bin,lib}, then on any given machine, /usr/{bin,lib} can be mounts/links to the native binaries (/usr64 or /usr32...)... Rational -- their rational was based on 8 year old data when x86-32 packages out numbered x86-64 packages. Clearly that doesn't apply on a modern x86-64 bit system -- where it's better than 3:1 64-bit (linux certainly has taken the lead on this). Existing 32 bit binaries would almost never work on a 64 bit system -- you would need to have the same libraries installed.. Does suse support taking 32bit binaries from 2004 and installing them on a 2012-suse12.1 system? If not, the justification for this is negated. What they don't mention is that existing programs are rebuilt, often from sources, and will build with the defaults for that platform. That being the case, it would require modification of those programs to work if their lib path wasn't "/usr/lib". Supporting non-recompiled binaries from 8 or more years prior, I don't think has ever been supported. What were they thinking? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 7

[opensuse] Re: Why bin & no bin64? => lets fix lib64=>lib, bin(32),lib(32)=>/usr32/{bin,lib}
by Joachim Schrod 01 Aug '12

01 Aug '12

David C. Rankin wrote: > > [On FHS] > So in the end, it failed to > accomplish its intended purpose. Instead standardizing on names and > locations, we invented GNU autoconf, libtool, etc. While I, very long time ago, put this unnamed female nutcase in my KILL file, I have to call BS on this statement. autoconf and libtool were there long before FHS came up. They were made to care for the differences of *UNIX(tm) systems*, and not for those minor differences of Linux distributions that the current rage is about. You know, about the situation that HP-UX was so POSIX compliant that you couldn't compile anything on it except the most portable software, or Perl with its old pre-autoconf configure. Or about AIX having strange ideas what Unix means. Nowadays, with Linux dominating the Unix landscape, portability is heaven, the uninformed rantings of the female nutcase not withstanding. Anyone but me still remember Eunice? Nowadays, it isn't even mentioned in Wikipedia any more. Once, Perl's Configure congratulated if you didn't compile for it. Or anyone else here who still remembers how kind of a fresh air V7 was when we got it in the early 80s -- and the UNIX(tm) wars that followed? Minor quibbles about Fedora / openSUSE / Debian / Ubuntu differences are nothing compared to these times. For your reading pleasure, I dig out two quotes that I encountered in that context: --------- Drew Mills writes: : A contest to see who could write the most useful script that could : actually be used in the most languages *as is* [...] I've written some scripts that work in 582 different languages, all of them named sh. -------- Larry Wall in some Usenet posting. You have to read -------- his original 4.x Perl Configure script to know what he's -------- writing about. These sometimes-posed-here questions about -------- bash are LOL if you look at his scripts. The posting -------- was probably made around 1990, before autoconf appeared. -------- (And yes, I dearly remember it's occurence on the scene.) -------- CREATED=92/03/17 OPENED=92/03/27 CLOSED=92/07/06 ERROR DESCRIPTION: the function prototype for fchmod() in the include file /usr/include/sys/stat.h is incorrect. the first parameter should be a file descriptor (int) not a string (char *). LOCAL FIX: PROBLEM SUMMARY: our current update scheme doesn't allow us to update header files. therefore, we will not ship this change. PROBLEM CONCLUSION: changes will not be shipped. TEMPORARY FIX: customer can edit the file themselves. change the first parameter of the fchmod call to (int) instead of (char *). -------- from IBM support, about AIX. Shows why autoconf was -------- invented. From openSUSE you'll hear many things, but not -------- they are "not allowed to update files". (The ticket was -------- opened by me, while on gold support contract from IBM; -------- this is not hearsay.) Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod(a)acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] Total Directory Size - http://download.opensuse.org/repositories
by Vickreman Chettiar 01 Aug '12

01 Aug '12

Hi. I am new to this mailing-list. I am considering having a private mirror of the entire /repositories directory from download.opensuse.org; and I need to know - what is the total size (i.e. including all files for all architectures) of the /repositories directory? Thank you to everyone on the mailing-list. Vickreman Chettiar - vickreman(a)gmail.com -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 2

Re: [opensuse-factory] Re: [opensuse] Re: Why bin & no bin64? => lets fix lib64=>lib, bin(32),lib(32)=>/usr32/{bin,lib}
by David C. Rankin 01 Aug '12

01 Aug '12

On 07/31/2012 01:54 AM, Linda Walsh wrote: > Anyway -- I am not suggesting getting rid of 32bit support. Just putting > in a 32-bit specific /usr32/{bin/lib} (only because some programs I've seen > rely on ../lib or expectations... Right. In essence, just implement the basic Linux FHS. Not the 'allowed' alternatives of /lib64, /usr32, just stick to the basic designations of /lib, /usr, etc.. And -- correctly implement those, i.e.: /lib Contains kernel modules and essential shared library images (the C programming code library) needed to boot the system and run the commands under /bin/ and /sbin/. Libraries are collections of frequently used program routines and are readily identifiable through their filename extension of *.so. They are essential for basic system functionality. Kernel modules (drivers) are in the subdirectory /lib/modules/<kernel-version>. To ensure proper module compilation you should ensure that /lib/modules/'kernel-version'/kernel/build points to /usr/src/'kernel-version' or ensure that the Makefile knows where the kernel source itself are located. see: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lib.html /usr /usr usually contains by far the largest share of data on a system. Hence, this is one of the most important directories in the system as it contains all the user binaries, their documentation, libraries, header files, etc.... X and its supporting libraries can be found here. User programs like telnet, ftp, etc.... are also placed here. In the original Unix implementations, /usr was where the home directories of the users were placed (that is to say, /usr/someone was then the directory now known as /home/someone). In current Unices, /usr is where user-land programs and data (as opposed to 'system land' programs and data) are. The name hasn't changed, but it's meaning has narrowed and lengthened from "everything user related" to "user usable programs and data". As such, some people may now refer to this directory as meaning 'User System Resources' and not 'user' as was originally intended. see: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

Re: [opensuse-factory] Re: [opensuse] Re: Why bin & no bin64? => lets fix lib64=>lib, bin(32),lib(32)=>/usr32/{bin,lib}
by Linda Walsh 01 Aug '12

01 Aug '12

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(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 1

[opensuse] LDAP errors flood at boot time 12.1
by danzl＠mbi-berlin.de 01 Aug '12

01 Aug '12

I'm getting a host of error messages of the following kind at boot. "worker_nscd: nss_ldap: failed to bind to LDAP server ldap://ldap.domain.com: Can't contact LDAP server" (this line ~20 times for both worker_nscd and cfagent) Hence /var/log/messages gets flooded by these messages and our users are confused by the boot up "failures". The error itself is non-critical. As soon as dhcp client is finished, which can take a while, the connection works just fine. What could I do to remedy the situation? TIA Naturally I would go for for customizing the service files, but for nscd and cfexecd (cfagent spanwing service) I have no systemd service files defined yet. Matt -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0