Wolfgang Rosenauer wrote:

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.

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

Am 31.07.2012 08:54, schrieb Linda Walsh:

Wolfgang Rosenauer wrote:

...

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.

---

Right...and if those apps ran 1% slower (IF), due to virtualization, you probably wouldn't notice it, right?

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.

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...

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

* Robert Schweikert [2012-08-05 14:09]:

On 07/31/2012 02:54 AM, Linda Walsh wrote:

...

Wolfgang Rosenauer wrote:

...

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.

---

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...

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.

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

* Graham Anderson [2012-08-06 00:31]:

On Sunday 05 Aug 2012 16:18:49 Guido Berhoerster wrote:

...

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.

I think this is incorrect, also I'm sure most of the nice SGI decks and boxes of the day were using MIPS archs.

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

Michal Hrusecky wrote:

Linda Walsh - 11:08 30.07.12 wrote:

...

Michal Hrusecky wrote:

...

Linda Walsh - 12:25 28.07.12 wrote:

...

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. AFAIK, we follow it, do you have any counterexample?

---

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.

I was asking for examples where we do not follow FHS ;-) By putting 64-bit native programs in the native /usr/lib directory.

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

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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

todd rme 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

---- 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

On Wed, 2012-08-01 at 13:14 -0700, Linda Walsh wrote:

todd rme 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

---- 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?

No patching needed... rpm --eval %configure => the the --libdir parameter? -- 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:

todd rme 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

---- 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?

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

On Wed, 01 Aug 2012 14:09:30 -0700, Linda Walsh 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.

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.

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

On Tue, 07 Aug 2012 18:33:04 -0700, Linda Walsh wrote:

Everyone?

And I am the only person who has different definitions from everyone?

WOW!

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

Brian K. White wrote:

On 8/7/2012 9:33 PM, Linda Walsh wrote:

...

Philipp Thomas wrote:

...

On Wed, 01 Aug 2012 14:09:30 -0700, Linda Walsh 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.

---

Everyone? And I am the only person who has different definitions from everyone? WOW! Are you really that self-centered?

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.

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

todd rme wrote:

That is why I specifically asked for packages "that would not need such workarounds under your scenario". Your scenario still requires the same workaround.

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

Robert Schweikert wrote:

...

There are about 1300+ packages in my /usr/lib64 dir.

I doubt you have packages in /usr/lib*, there should only be files, links and directories. Packages may install these files, links, and directories.

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