Revisiting ideas

[Dan Nicholson]

On Wed, Apr 30, 2008 at 6:35 AM, Alexander E. Patrakov
<patrakov at gmail.com> wrote:
> Dan Nicholson wrote:
>  > I agree that there are major advantages to splitting the libraries out
>  > of the package, but why can't you just update the whole openssl
>  > package to get the library update? In fact, the -devel split you're
>  > talking about where the bare .so links and the headers are in a
>  > separate package wouldn't affect a library update in any way. In most
>  > cases, the .so.* links are part of the main package anyway (including
>  > openssl).
>
>  Think about the way dependencies are expressed. The automatic dependnecy
>  extractor says: "package cryptofoo [that was built before openssl upgrade]
>  depends on libssl.so.0.9.8 due to library dependencies". If you attempt to
>  upgrade the whole openssl library to 0.9.9 (i.e. a binary incompatible
>  release--that's important) without the split, the package manager will not be
>  able to do this, because the new package does not provide libssl.so.0.9.8 and
>  thus the cryptofoo package's dependencies are not satisfied with the new openssl
>  package. I.e., with such incompatible upgrades, it is convenient to have the
>  following installed during the transitions: old openssl dynamic libraries
>  without the .so symlinks, new openssl dynamic libraries with the .so symlinks,
>  new headers. You can't have all three at the same time without splitting the
>  package (assuming that the package manager knows about file conflicts).

I certainly agree that it's best to handle situations like that, but
does RPM even support it? I.e., if I split off a libssl subpackage
that just has libssl.so.0.9.8, would RPM even allow me to install a
newer version of libssl in parallel without --force or something? I
don't know much here, but it seems that Fedora is getting along fine
without putting libraries in separate subpackages. On the other hand,
I notice that Debian/Ubuntu always splits the libraries into separate
packages.

--
Dan