RFC: Soname in rpm name

[Jeff Spaleta]

On Thu, 27 Jan 2005 21:52:18 +0100, Aurelien Bompard <gauret at free.fr> wrote:
> > Another argument which has been made for continuing in this fashion is
> > that  standardizing on using sonames in all library packages
> > potentially lowers the bar to backward-compatibility cruft. Such
> > libraries would linger in an unknown maintainership state and be
> > difficult to drop at any point because there will always be users who
> > are using legacy application that needs that legacy library.
> 
> Very true, and that's what Axel's proposal to introduce a virtual Provides
> is trying to solve. With it, a simple "rpm --whatprovides
> shared-library-package" returns all the library packages.

I dont think the shared-library-package provides solves the cruft
problem from the project perspective.  From the user perpective yes 
the provides hack will be a somewhat useful mechanism for users/admins
 to cull cruft from their boxes. But i don't think thats what Ville
had in mind when making the argument. I think Ville was talking about
how the project as a whole prevents itself from accumulating layers
and layers of library cruft that become harder and harder to maintain
as time goes by because there is less and less upstream interest in
maintaining the aging codebase.  Its easy to package up an old library
and offer it.. it gets harder and harder to 'maintain' such a package
with critical and security related patches if the upstream development
interest has dried out.  I think Ville's arguement is aimed at making
sure that whatever policy Core is using doesn't encourage the
accumulation of difficult to maintain legacy libraries for which users
are expecting to be able to be maintained at a high standard.

> 
> Now we need a way to actually expire the old libraries. Proposals have been
> made in this direction to flag what the user has directly asked for and
> what was brought in as a dependency. In which case the library could be
> garbage-collected (if nothing depends on it anymore).
> This would be great, but I don't know how much work it would require to
> implement it in rpmlib (and in wrappers maybe ? maybe not needed)

Again these solutions have focused on the user's perspective of how to
garbage collect unused libraries. That is not the crux of my concern.
I've been trying to talk about a mechanism by which the package
authors can expire a library.. thus notifying ALL users of that
particular package that the author is no longer going to be providing
any maintence for that library. And when the package authors have
decided to expire the library.. the secure thing to do is to remove
that library from the system regardless of what applications are still
using it, until a new package author can be found for that library who
is willing to 'maintain' the library.  This is what effectively
happens when core drops libfoo.so.1  from package libfoo and adds
libfoo.so.2 instead. When the installer is used to upgrade to the new
Core, any package that depends on that old libfoo.so.1 library breaks
or gets removed.  Sucks for the user that doesn't care about running
vulnerable code.... sucks marginally less for a user who wants to make
sure they aren't going to be opening themselves up to a future
vulnerability that won't get patched with an update.

The garbage collecting ideas address a different problem altogether
than the 'expiration' issue i see the current core naming scheme being
implicitly used for in some situations.
Every if you garbage collected.. you still don't have a clue about
whether the original author is going to be issuing updates anymore for
a libfoo1 package that you are still using for a number of
applications in the soname in packagename scheme. Keeping the libfoo
package  name across soname versions implicitly defines an enforced
expiration policy by the package author.

-jef