RFC: Soname in rpm name

[Axel Thimm]

On Mon, Jan 24, 2005 at 08:27:59PM -0500, Jeff Spaleta wrote:
> On Tue, 25 Jan 2005 02:02:51 +0100, Axel Thimm <Axel.Thimm at atrpms.net> wrote:
> > OK, neither will the soname-in-the-rpmname address this in any way,
> > positive or negative, and as said the issue you raise is far more
> > involved and w/o any good solution. The leaf detection would
> > circumstantially help here, but that wouldn't be the main focus.
> 
> On the other hand   keeping packages the same name when an older
> soname expires handles the case i bring up exceedingly well.   package
> libfoo in fc3 provides libfoo.so.1   package libfoo in fc4 provides
> libfoo.so.2. Upgrades from fc3 to fc4  and libfoo.so.1 is no longer on
> the system.  Works like a charm at keeping unmaintained library
> versions off the system. It works so well in fact.. that it almost
> seems like it was a design goal for naming library packages without
> sonames.

That's been taken care of the garbage collection mentioned here.

What is not taken care of and is a real problem you touched is if a
package becomes deprecated with no upgrade path and rotts in your N
times upgraded system. But that off-topic in this context. The
soname-in-rpmname neither helps nor hurts.

> And thats the point I'm trying to make. Moving to a per soname when
> its absolutely not needed

Not needed? Let's not reiterate the whole discussion. There is added
value in having the libraries coinstallable like they are meant to
be. If you need arguments for it just insert arguments for having
library verioning at all at this spot.

> has consquences for other aspects of packaging.  As soon as the
> proponents for a soname-in-the-rpmname have a workable proposed
> solution to the problem I bring up, I'll gladly stop bringing it up.

Well, you raised a topic that is not really related to the
soname-in-rpmname. And whatever is indeed tangentially related the
Provides: hook and garbage collection method has its ways of dealing
with it better than the current compat-whatever packaging.

So at the end of the day you have a win-win situation.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050125/4e30f30e/attachment.sig>