All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, John Levon <levon@movementarian.org>
Subject: Re: Re: [Xen-changelog] [xen-unstable] tools: Rationalise library soname versions.
Date: Mon, 10 Dec 2007 14:24:52 +0000	[thread overview]
Message-ID: <20071210142452.GA12703@redhat.com> (raw)
In-Reply-To: <18269.3602.133295.386977@mariner.uk.xensource.com>

On Mon, Dec 10, 2007 at 09:59:46AM +0000, Ian Jackson wrote:
> Daniel P. Berrange writes ("Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] tools: Rationalise library soname versions."):
> > IMHO, the entire rationale of setting all the sonames in one place is just
> > plain wrong. Libraries evolve independantly and thus their sonames change
> > independantly. Tieing sonames to the software release version number does
> > not reflect the reality of their ABI evolution. sonames should only be
> > changed when an existing API changes in a non-backwards compatible manner
> > so its perfectly normal for an soname to stay the same across multiple
> > releases if nothing changes, or merely new APIs are added without changing
> > existing APIs.
> 
> In principle I agree with you.  However, in practice the project has
> not been able to maintain the discipline needed to bump a soname when
> the ABI changes.  Until this change, all of the libraries in
> xen-unstable were claiming ABI-compatibility with 3.0 which was
> definitely not correct.  Bumping the version numbers at release time
> is at least something we can probably manage to do reliably.
> 
> This is perhaps slightly inconvenient but since the dom0 toolstack and
> hypervisor generally don't maintain good binary compatibility across
> releases anyway I don't think there's that much lost.  Do you
> disagree ?

I am fine with libxc.so having its soname change each release, since the
libxc ABI does change all the time. There is no need to force the soname
to match the software release version - they may happen to coincide, but
there's no need to force it if there weren't changes - that said I expect
libxc.so will continue to change every release. libxenstore and libfsimage
have actually been stable & thus don't need to change artificially. 

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

  reply	other threads:[~2007-12-10 14:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200712080030.lB80UAdN016166@xenbits.xensource.com>
2007-12-08  1:46 ` [Xen-changelog] [xen-unstable] tools: Rationalise library soname versions John Levon
2007-12-08 17:17   ` Daniel P. Berrange
2007-12-10  9:59     ` Ian Jackson
2007-12-10 14:24       ` Daniel P. Berrange [this message]
2007-12-10 14:56       ` John Levon
2007-12-10 15:00         ` Ian Jackson
2007-12-10 15:02         ` John Levon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071210142452.GA12703@redhat.com \
    --to=berrange@redhat.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=levon@movementarian.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.