Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Posted Oct 8, 2009 17:45 UTC (Thu) by rgc (subscriber, #36411)
If you have a distro that wants to enable selinux (or any other cross-app functionality) and another one that wants nothing to do with it, that gives you incompatible library dependencies from the start.
Some distros insist in modifying upstreams to comply with file location policies (think plugin paths) while other distros insist on unmodified upstreams.
Distros migrating now to upstart may want to change the location (maybe even syntax!) of their init scripts, while conservative distros want to keep the current ones.
Several distros are trying approaches to multiarch, with differing implementations regarding file locations. A cross-distro policy for that will necessarily have to wait until a winner is selected, if one ever is, since they might be serving different trade offs.
There's probably a couple other dozen of examples, I'm just trying to give a feel of what I mean.
Posted Oct 8, 2009 17:55 UTC (Thu) by khc (subscriber, #45209)
You can solve that specific problem by using file based dependency, but then you have other problems too (where to put the files, what files to package).
Posted Oct 9, 2009 16:11 UTC (Fri) by sorpigal (subscriber, #36106)
There isn't even any consensus on representing version information. Debian's notion of what kind of version string is "higher" is different from Fedora's, even if the package format were the same.
Posted Oct 8, 2009 18:23 UTC (Thu) by nevyn (subscriber, #33129)
To see what was meant let's take a look at say, openssl, in both Fedora and OpenSuSE. They both use rpm, and are even moving towards having the same version of rpm, so the difference is mainly "policy".
This is a huge difference already, and will propagate throughout the entire distro.
Again, a major difference. Yum certainly doesn't understand what the -32bit suffixes mean (so multilib_policy won't work).
Again, this is a policy which is going to propgate thought the distro. There is no solution to this apart from "merge policy" or "have two separate packages".
The contents of those directories is also very different. Again, this is a "merge or rebuild" type problem.
Again, even if everything else matched installing the OpenSuSE packages on Fedora could blow everything up due to this difference.
Opps, any binaries linking to ssl can't move between distros. now because they have different .so numbers.
Again, major change.
And that's the obvious policy differences seen in a few minutes on one package (due to the different split of packages and files, I didn't really try to see investigate file differences), where both distros. have the same upstream version: 0.9.8k. So you have to "fix" all of the above, and more, to have something you can realistically share between those two distros. (where fix means someone changing their policy, which isn't going to happen without a large fight) ... as the above poster said, the packaging format is the least of your problems.
Posted Oct 24, 2009 15:59 UTC (Sat) by jengelh (subscriber, #33263)
One reason is simple: because rpm -Uhv openssl-1.0 would eliminate all packages of the same name with a lower version number.
And since it does not use yum (thankfully), there is nothing to worry about multilib_policy.
>Fedora names the libraries /usr/lib64/libcrypto.so.0.9.8k _and_ /usr/lib64/libcrypto.so.8. OpenSuSE names the libraries /usr/lib64/libcrypto.so.0.9.8. Opps, any binaries linking to ssl can't move between distros. now because they have different .so numbers.
You could blame openssl for that, because they are not using the library versioning scheme "correctly" (by the definition of the libtool manual). Either libcrypto.so.X with proper X, or libcrypto-0.9.8.so(.0).
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds