libfoo<major> (was: Incoming: directfb soname problems)

[Axel Thimm]

On Sun, May 14, 2006 at 03:53:06PM -0500, Tom 'spot' Callaway wrote:
> On Sun, 2006-05-14 at 21:12 +0200, Thorsten Leemhuis wrote:
> > Am Sonntag, den 14.05.2006, 20:37 +0200 schrieb Nicolas Mailhot:
> > > Le Dim 14 mai 2006 07:13, Michael A. Peters a écrit :
> > > > On Sun, 2006-05-14 at 00:25 +0200, Axel Thimm wrote:
> > > >> Maybe it's time to think about packaging so into their separate
> > > >> libfoo<major> subpackages like Debian/Mandrake/ATrpms are doing? This
> > > >> always ensures forward and backward compatibility at the cost of dead
> > > >> libfoo<major> packages lying around.
> > > > I semi agree.
> > > And I semi disagree.
> > 
> > How about a policy like this:
> > 
> > ---
> > Package updates in Fedora Extras to new upstream version are allowed for
> > stable Core versions as long as the soname of the provided libs doesn't
> > change. 

Almost always the packager won't even notice, 99.9% of the specfiles
have *.so.* in %files.

> > Updates with soname changes are okay if the packager takes care of one
> > of the following steps: 

Sometimes one might not even know what other packages depend on the
lib's major. E.g. a packager would need to check all relevant repos
for all relevant distros to see whether another package depends on his
previous so version.

> > a) you create and provide a compat-package with the old lib in it. The
> > compat-package of course needs to be parallel-installable with the new
> > version.
> 
> Also, the new "compat" package needs to be reviewed as if it were a new
> package. We've already set precedent for this with wxGTK.

In the case of libfoo<major> idioms you don't need the review: The
"compat" package was in productive use all along.

The larger Fedora package space becomes the more often one will be
confronted with this kind of obstructions. Either a major bump will
require a chain of rebuilds, or even worse some packages will really
depend on the previous major version of the lib (after all the major
bump should really indicate an API change).

In the case of ATrpms the libfoo<major> idiom even makes it possible
to stay compatible with other repos (in fact that was the original
motivation), as different repos build on different so versions or
upgrade to new versions at different pace. Similar for Debian and
Mandriva where the package space is too large to coordinate within one
time unit.

> Otherwise, I'm in total agreement here.
> 
> ~spot

-- 
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-extras-list/attachments/20060515/b2a71e09/attachment.sig>