How to handle soname bump properly?

[Todd Zullinger]

Peter Lemenkov wrote:
> Consider, we got library libfoo and dependent utility bar.
> 
> If I updated library libfoo (successfully built with soname
> increased, and ready to hit updates-testing via Bodhi), then how
> should I udate bar?

This is something that requires some help from rel-eng.  You would
build libfoo and then mail rel-eng at fedoraproject.org asking for a
build root override for libfoo (providing the full n-e-v-r or cvs tag
for the libfoo build you want to be in the build root) and often some
brief justification for the request (like, "I need this to build bar
against in order to fix outstanding bugs").

They sprinkle some pixie dust and let you know when it's done.  Then
you can build bar against the new libfoo and push both of them as a
single update to updates-testing via bodhi.

(Of course, you should already have done some testing of this in
rawhide and locally for the affected stable release and thought hard
about whether a soname bump in the stable release warranted -- that
the benefits of the bump outweigh the drawbacks.)

> If I rebuild bar, then against what version of libfoo it will be
> rebuilt? Against old one or against new, which still not submitted to
> updates-testing (to avoid unresolved dependencies).

It would be built against the older version, which is obviously not
what you want.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mollison's Bureaucracy Hypothesis:
    If an idea can survive a bureaucratic review and be implemented it
    wasn't worth doing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080712/ae1b1cfc/attachment.sig>