Packaging summit [LWN.net]

Packaging summit

Posted Oct 8, 2009 18:23 UTC (Thu) by nevyn (subscriber, #33129)
In reply to: Packaging summit by DOT
Parent article: A report from the RPM summit

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

Fedora has openssl, openssl-devel, openssl-perl, openssl-static.
OpenSuSE has compat-openssl097g, libopenssl0_9_8, libopenssl0_9_8-devel, openssl, openssl-doc, openssl-ibmca-32bit, openssl_tpm_engine.

This is a huge difference already, and will propagate throughout the entire distro.

Fedora has .x86_64, .i586 and .i686 arches in it's x86_64 repo.
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).

Fedora has /etc/pki/tls and /etc/pki/CA
OpenSuSE has /etc/ssl

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

Fedora puts the documentation in the openssl package in /usr/share/doc/openssl-0.9.8k
OpenSuSE puts the documentation in the openssl package in /usr/share/doc/packages/openssl

The contents of those directories is also very different. Again, this is a "merge or rebuild" type problem.

Fedora has /usr/lib/.lib*.hmac files, for FIPS certification
OpenSuSE doesn't

Again, even if everything else matched installing the OpenSuSE packages on Fedora could blow everything up due to this difference.

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.

Fedora puts the ssl shared objects in /usr/lib64/openssl/engines
OpenSuSE puts the ssl shared objects in /usr/lib64/engines

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.

(Log in to post comments)

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