| |||||||||||||
Packaging summitPackaging summitPosted Oct 8, 2009 16:41 UTC (Thu) by DOT (subscriber, #58786)In reply to: Packaging summit by rgc Parent article: A report from the RPM summit
What kind of policies are you talking about? Can't a powerfully expressive system deal with varying policies?
(Log in to post comments)
Packaging summit Posted Oct 8, 2009 17:45 UTC (Thu) by rgc (subscriber, #36411) [Link]
Some scenarios that come readily to mind:
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.
Packaging summit Posted Oct 8, 2009 17:55 UTC (Thu) by khc (subscriber, #45209) [Link]
package naming policy matters too. If package A depends on libB-4, another package that provides the same thing but calls itself B-4 wouldn't satisfy that.
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).
Packaging summit Posted Oct 9, 2009 16:11 UTC (Fri) by sorpigal (subscriber, #36106) [Link]
Where to put the files isn't all of it. You can have the same version of a lib compiled with different compile-time options which could affect compatibility.
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.
Packaging summit Posted Oct 8, 2009 18:23 UTC (Thu) by nevyn (subscriber, #33129) [Link] 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.
Packaging summit Posted Oct 24, 2009 15:59 UTC (Sat) by jengelh (subscriber, #33263) [Link]
>OpenSuSE has .x86_64 only, with some "duplicates" which have a suffix of -32bit. Again, a major difference. Yum certainly doesn't understand what the -32bit suffixes mean (so multilib_policy won't work).
One reason is simple: because rpm -Uhv openssl-1.0 would eliminate all packages of the same name with a lower version number.
>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).
|
|||||||||||||