[opensuse-factory] Re: [opensuse] Re: Why bin & no bin64? => lets fix lib64=>lib, bin(32),lib(32)=>/usr32/{bin,lib}
Michal Hrusecky wrote:
I gave a bunch of statistics 35% of the binaries in bin are 64bit. bin contains only 25% of the overall packages, so only 20% of the libraries in lib & lib64 are 32-bit. The rest are 64-bit. The original reasoning was continued and widespread usage of 32-bit programs. However, If I look at what those 32-bit programs are supporting -- in bin: master-boot-code-1.22-7.1.2.i586 sas_ir_snmp-3.17-1092.i386 sas_snmp-3.17-1092.i386 sas_snmp-3.17-1092.i386 sas_ir_snmp-3.17-1092.i386 sas_ir_snmp-3.17-1092.i386 ---- Suse's boot code. and some 3rd party snmp HW drivers that I don't run or need. So we have 20% of the libraries reserving 65% of /usr/lib for 1 suse program? Um... is that a good enough counter example?
---- Can't think of too many examples, most are because they haven't gotten a new version out yet. Can you think of a counter-example? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 30.07.2012 20:08, schrieb Linda Walsh:
I can give you examples for 32bit applications I use and need on my Linux box: Skype moneyplex (online banking) Android SDK (probably a few more less important ones) I don't care for the megabytes some 32bit libraries use on my systems harddisk if I can run the above applications successfully. That's a very small price. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Wolfgang Rosenauer wrote:
Right...and if those apps ran 1% slower (IF), due to virtualization, you probably wouldn't notice it, right? That's assuming none of those couldn't or wouldn't be updated.... At one point Adobe was dragging their heels with Flash, but I think the threat of Flash being left behind as people moved to HTML5 based solutions might have persuaded them to be more flexible. Still Mozilla is dragging their feet on 64 bit support on Windows -- but that didn't stop their directories from being virtualized nor the 32-bit program directories being moved. Interesting how they didn't create the roadblocks on linux as they have on Windows... 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... Might require less script-based changes if they use relative paths. Many of the binaries can be changed with some build macro changes... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 30 Jul 2012 23:54:29 -0700, Linda Walsh <suse@tlinx.org> wrote:
Interesting how they didn't create the roadblocks on linux as they have on Windows...
Maybe it's MS's idiotic idea of pointers not fitting into longs and tons of code that make that assumption?
And at least I fail to see the merrit of that besides aesthetic reasons. IMNSHO this would create a huge amount of work for nothing. Philipp -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 31.07.2012 08:54, schrieb Linda Walsh:
Actually I have no idea at all what's the problem with the current approach. I might have missed the point in the earlier discussion but I see no problem which needs fixing. But setting up one or more virtual machines just to run a 32bit application is overkill even if performance is not critical.
You are talking about Mozilla? Then because I and other Linux fellows from other dists have worked hard to make 64bit builds of Mozilla as soon as possible. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/31/2012 02:54 AM, Linda Walsh wrote:
There is a bit of a historical component you appear to be neglecting. The 64 bit stuff came after 32 bit implementations and by the time 64 bit came about on UNIX the directories had long been named without numerical components, thus /usr/lib and /usr/bin had been around for a very long time. To preserve compatibility for applications not under the control of the OS vendors the existing naming scheme remained untouched and the *64 stuff was added. This all happened long before anyone even spoke of Linux in a commercial setting. Had the GNU system broken these conventions it would not have had much success on the UNIX platforms and had Linux distributions not followed established practice we might not have had the success we have seen. Now all of this does not say things are written in stone and should not be changed, or maybe the odd cases should be fixed, but we cannot just go out and change stuff because you happen to not like certain things. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Robert Schweikert <rjschwei@suse.com> [2012-08-05 14:09]:
Do you have any references for that? As far as I'm aware IRIX was the only commercial Unix to use */lib64 and this subsequently became a linuxism. Even Debian initially used /usr/lib/64 subdirectories and has now again moved off of lib64. Solaris has always had platform-specific subdirectories and NetBSD an altenrate root. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 05 Aug 2012 16:18:49 Guido Berhoerster wrote:
I think this is incorrect, also I'm sure most of the nice SGI decks and boxes of the day were using MIPS archs. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Graham Anderson <graham.anderson@gmail.com> [2012-08-06 00:31]:
It is correct, IRIX 6 supported both 64 and 32-bit (of course on mips3/4) and apparently set a bad precedent for Linux. The Point is that other Unix variants solved this in a smarter way around the same time and now even a significant portion of Linux in form of Debian and its derivatives is finally moving towards such a solution [*]. * http://wiki.debian.org/Multiarch/TheCaseForMultiarch -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Linda Walsh - 11:08 30.07.12 wrote:
I was asking for examples where we do not follow FHS ;-) -- Michal HRUSECKY SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal Hrusecky wrote:
The FHS says they belong in the /lib64 directory Why the intermix 32 and 64 bit programs though is a bit odd... I doubt that standard 64-bit programs are supposed to link with /usr/lib either, though most do -- I'll often see messages about the linking ignoring incompatible libraries in lib -- a 64-bit build should look in the 64-bit dirs first... The problem, is that the majority of programs have to be modified to fit the FHS, while the minority of legacy programs that would work equally well in a 32-bit root, push the native apps out of place. This despite their putting IA64 libraries in /usr/lib (despite Intel including i386) compatible options with their IA64's .. But it wasn't native there either. So why x86_64? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Aug 1, 2012 at 6:11 AM, Linda Walsh <suse@tlinx.org> wrote:
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
todd rme wrote:
---- There are about 1300+ packages in my /usr/lib64 dir. The default on packages coming with config would have been /usr/lib. That's 1300 packages that had a have a special patch applied (75% of total). Seems like not having to go out of one's way to patch away from what is the 'normal expected path', would be more than aesthetics.... FWIW, with opensuse, the 'fhs' package is an optional install. There is no requirement that openSuSE without fhs installed be FHS compatible, is there? Or is openSUSE FHS compatible without the FHS package installed? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 01.08.2012 22:14, schrieb Linda Walsh:
Hmm, I cannot remember that I needed to patch a package to install its libs into /usr/lib64. Still not sure what you are talking about. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2012-08-01 at 22:23 +0200, Dimstar / Dominique Leuenberger wrote:
Oh, before you go an patch away the /usr/lib64 there: keep in mind what would happen with the biarch install. See this example: - I run a x86_64 system - I have /usr/lib64/libfoo.so.1 installed (from libfoo1-1.0-xx86_64.rpm) - I install application bar. It's nicely shipped as a binary, as it's a commercial application, non-free, non-open.. yet, I need it. But: oh dang: it's a 32bit application... and it requires libfoo.so.1; obviously, it can't load the one I have in my system. so, in openSUSE, I go and install libfoo1-32bit, et voila! I'm done and I can start 'bar'. Pretty cool, eh? Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Aug 01, 2012 at 01:14:23PM -0700, Linda Walsh wrote:
Actually no, as %configure RPM macro does that for you automatically. And there is of course reasoning behind that, and it is defined for us. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Marcus Meissner wrote:
Does what? Install FHS? I'm not clear as to the referent of 'that'.
And there is of course reasoning behind that, and it is defined for us.
Ciao, Marcus
---- Guess it depends on what you mean by patch. Since I build from pre-rpm sources on releases that are not in the SuSE system yet, (i.e. no source RPM has been created yet), I'm going off of the standard config values. Rpm applies it's set of standard patches to create a config -- though those are unique per product in many cases...(samba different from perl different from squid)... Many have their own sub dirs added others don't. There's alot of hand-touch in there from what I have seen -- and it's not always consistent. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 01 Aug 2012 14:09:30 -0700, Linda Walsh <suse@tlinx.org> wrote:
Guess it depends on what you mean by patch.
Almost everyone agrees on what a patch is, only you seem to once again have your own definition.
But even then it is as easy to pass the same parameters as rpm does, and still nothing resembling a patch. Philipp -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Philipp Thomas wrote:
Everyone? And I am the only person who has different definitions from everyone? WOW! Are you really that self-centered? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 07 Aug 2012 18:33:04 -0700, Linda Walsh <suse@tlinx.org> wrote:
Yes, WOW that you think that a patch, i.e. a piece of text that can be fed to patch(1) to apply changes is the same as passing parameters to configure.
Are you really that self-centered?
I don't think so, but your mails to the lists show rather clearly that you seem to be. Philipp -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/7/2012 9:33 PM, Linda Walsh wrote:
From where I'm sitting, it's not him who most exhibits that trait. Not agreeing with you on a topic that does have some room for argument is not a definition of self-centered. Not agreeing with you about something that can be simply demonstrated at any time leaving no room for argument, is even less so. Not tolerating anyone else disagreeing with you, and not hearing what everyone else is telling you even when they can demonstrate that what they say actually works and can demonstrate that what you're saying doesn't work actually does, is consistent with and a subset of a description of self-centered behavior. I have my own topics where I disagree with the majority here, but I do know the difference between a position and a fact, and I do know the difference between my wishes and a universal truth for everyone or for most. It's possible to have a theory that would be better for everyone, that everyone else has so far not considered yet. It's possible to be the first one with the next level of best practices that everyone else should adopt. But you have so far entirely failed to defend, or even properly explain and back up your ideas. As it stands, you just seem to want some things no one else wants. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Brian K. White wrote:
I'm not the one claiming that everyone agrees with my opinion and the the other person "has their own definition. If you think everyone agrees with you, and I'm the only person with my opinion, then my comments were appropriate. I know I have a minority opinion, but that doesn't mean it is a singular opinion. You on the other hand seem to believe your "dream-think" is the view of the majority - but in one respect you are right, the majority do think they world thinks like them and they are are somewhere in the middle... Yup... I'm a single unique individual...um...just like everyone else. >:-> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Aug 1, 2012 at 10:14 PM, Linda Walsh <suse@tlinx.org> wrote:
Even if they needed a patch, which they don't, we would need roughly the same patch for the same packages in order to get the 32bit libs in /usr/lib32/. So we don't gain anything in this regard by switching, we just change which arch get the "patch". That is why I specifically asked for packages "that would not need such workarounds under your scenario". Your scenario still requires the same workaround. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
todd rme wrote:
My scenario would be to take a similar approach as on Win, which involves virtalizing the lib for the non native arch, OR for all archs and have lib be a redirector. Then all the programs that try to install in /usr/lib, will be find and not need patching to go into /usr/lib64. AFA which packages are in /usr/lib64... I've posted the list on my machine. It will vary. My usr/lib: 210 x86_64 (subtracting 32bit packagenames) 286 32bit 35 ??noarch? === 531 total my usr/lib64: 1459 x86_64 1459 total If you want to talk amount of patch .. I have 1459 that are reloc'ed to 1459 210 that are not. And 286 32bit packages. The 32-bit packages are in the minority on my system. That may not be true on all systems... That's why I suggested giving 32-bit programs a separate namespace that has the 32-bit libs mounted at /usr/lib and all else the same. (or virtualized env, or some autoredirect)... It seems like if the loader just made sure they were launch with the correct namespace view, no patches would be needed for either... (or any other arch...). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 08/01/2012 04:14 PM, Linda Walsh wrote:
I doubt you have packages in /usr/lib*, there should only be files, links and directories. Packages may install these files, links, and directories.
FHS compliance is a check that is part of rpmlint that runs in OBS when a package is built. Whether the fhs package is installed or not is irrelevant for FHS compliance.
Or is openSUSE FHS compatible without the FHS package installed?
yes -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Robert Schweikert wrote:
In case you missed my methodology posted at least a few times: rpm -qf /usr/lib/*|sort|uniq That will tell you how many uniq packages have files in the dir. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (12)
-
Brian K. White -
Dimstar / Dominique Leuenberger -
Graham Anderson -
Guido Berhoerster -
Jan Engelhardt -
Linda Walsh -
Marcus Meissner -
Michal Hrusecky -
Philipp Thomas -
Robert Schweikert -
todd rme -
Wolfgang Rosenauer