Xen devel - Dec 2007 - Re: [Xen-changelog] [xen-unstable] tools: Rationalise library soname versions.

On Fri, Dec 07, 2007 at 04:30:09PM -0800, Xen patchbot-unstable wrote:
> tools: Rationalise library soname versions.
> 
>  * Arrange for the sonames of libxenstore, libxc, libfsimage and
>    libblktap to be set from a single place in Config.mk.
Grumble... I don''t like this at all. You just bumped libfsimage for no
reason. Can we please fix libfsimage back to the correct versioning?
(that is 1.0.0)

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sat, Dec 08, 2007 at 01:46:57AM +0000, John Levon
wrote:
> On Fri, Dec 07, 2007 at 04:30:09PM -0800, Xen patchbot-unstable wrote:
> 
> > tools: Rationalise library soname versions.
> > 
> >  * Arrange for the sonames of libxenstore, libxc, libfsimage and
> >    libblktap to be set from a single place in Config.mk.
> 
> Grumble... I don''t like this at all. You just bumped libfsimage
for no
> reason. Can we please fix libfsimage back to the correct versioning?
> (that is 1.0.0)
Likewise xenstore has just been bumped for no reason. The total diff
of the public xenstore head between current 3.1.x releases and unstable
is just

$ diff -u xen-3.1.0-testing.hg/tools/xenstore/xs.h
xen-unstable.hg/tools/xenstore/xs.h
--- xen-3.1.0-testing.hg/tools/xenstore/xs.h    2007-04-23 19:19:32.000000000
-0400
+++ xen-unstable.hg/tools/xenstore/xs.h 2007-10-01 12:03:55.000000000 -0400
@@ -112,7 +112,6 @@
 
 /* Start a transaction: changes by others will not be seen during this
  * transaction, and changes will not be visible to others until end.
- * You can only have one transaction at any time.
  * Returns NULL on failure.
  */
 xs_transaction_t xs_transaction_start(struct xs_handle *h);


This is not ABI incompatible and thus libxenstore should *not* have its
soname changed.

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.

Please revert this change and only adjust the soname of libraries which
have actually changed since the previous 3.1.2 release, which AFAICT
is only libxc.

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  -=| 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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 ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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  -=| 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.
Please change libfsimage back. I am watching it carefully and as the
original author I do not want or intend the ABI to change (certainly not
incompatibly).

Indeed originally I hoped that this would be packaged separately from
Xen, but it didn''t work out like that alas.

Tying a generic library''s interface version to Xen''s
non-stable, mostly
non-usable library interfaces is 100% wrong.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

John Levon writes ("Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable]
tools: Rationalise library soname versions."):
> Please change libfsimage back. I am watching it carefully and as the
> original author I do not want or intend the ABI to change (certainly not
> incompatibly).
OK.  Thanks a lot.  It''s good that you''re watching it and
certainly I
wouldn''t want to introduce gratuitous soname bumps if someone is
paying attention to make sure that we put a soname bump in where
needed.

Formal patch will follow.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Dec 10, 2007 at 02:56:51PM +0000, John Levon wrote:
> Please change libfsimage back.
Dan kindly pointed out it /has/ been reverted - please ignore :)

cheers
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel