Claudio Freire wrote:
On Tue, Apr 2, 2013 at 4:57 AM, Linda Walsh
wrote: If your libs don't work without the patches, it means the patches are needed for binary compatibility. You don't want the patches? Tough luck.
It's not the patches that are needed but symbols that are needed -- If I don't use features you have bound in, the code doesn't travel those paths. It's like in gvim when configured correctly, -- if I don't use python, it doesn't load it -- so the binary version doesn't matter.
If the OWL extensions had been put in their own lib and dlloaded at run time, I wouldn't have to worry about patching them or including them.
No, you're completely wrong there. Take it from someone that actually does some coding for his livelihood, any kind of patch has the potential to break binary compatibility.
In this case, you are wrong. The same patch went into glib 2.14, 15, 16 and 17. The patch hasn't changed. That means since glibc17 includes binary compat for glib2.14, if suse had put it into a separate library and not modified the standard glibc, there never would have been a problem. You'd have to know how C
works pretty well to be able to decide whether one in particular does or does not. It's not just about the symbols.
I know C pretty well. I've kernel code, compiler code interpreter & graphics code, networking (before TCP/IP). Worked in 8080/8085/x86 assembler as well as I worked at intel in their compiler group. My degree is in computer science -- so I had an engineering degree background to back up my job experience -- not something alot of people writing code today can say. I owned and programmed a and worked on a 4.77MHz PC, original IBM, got through an Intel price break. I have a passable to mediocre knowledge of much of the computer science field. People outside the computer industry consider me an expert, but I wouldn't call myself that. There's way too much to know to be an expert except in very narrow knowledge areas -- and my interests are spread way to widely to become an expert in any of them. In the specific example, suse created unnecessary binary incompatibility between the standard libc and theirs. If they had put it in a separate library, that could be run-time loaded, Perhaps via modification of the LD_LIBPATH, then they could have had the binary compatibility with glibc that vendors would like. But so many utils wouldn't load because they couldn't find a symbol "OWL_1.0" - a 3rd party crypto addition. Most of those utils had no need for encryption. So I maintain that bundling such things is a major headache for users who try to support 3rd party tools (or write them).
Like the ones that break normal functionality applied to BASH or break parallel sorting?
All the ones you don't need to remove, keep them. They're quite likely modifying the lib's ABI, so you have to keep them.
Nope they were both bugs that disabled standard functionality.
There's probably a reason though. The package's ABI must be especially unstable, and backwards compatibility especially unreliable for the packager to do that.
Except that it's not. The ABI is guaranteed stable over the minor releases in perl, for example, yet suse locks many products into minor versions requiring upgrading an entire distro to upgrade your perl.
Yes, it was you. You installed a broken libc, if I read the OP correctly. Broken by you by not building it to openSuse specs.
By having 'cat', cp, ls all require a crypto lib, suse is breaking things unnecessarily. You can claim I broke it because I didn't add crypto into a lib for cp or cat or whatever... BUT those things don't use crypto and I don't use the crypto in that lib! Suse broke it first by force all utils to be dependent on mandatory crypto symbols bundled into libc. They are NOT depedant on the crypto CODE, they are only dependent on the extra added symbols added at link time. That's deliberate breakage of 100's of programs that don't need to be broken. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org