Re: library versioning: making upstream policy, need debian evaluation.
Junichi Uekawa <dancer@netfort.gr.jp> writes:
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
So it looks like one of the recommendations here (and something I was
considering for gwrap) is to just require particular versions of
sub-libraries in ./configure so that *your* library's soname really
does mean binary compatible.
If I'm understanding correctly, the doc above also indicates that
ideally, you should work with the upstream to get the soname bumped
whenever one of that library's sub-libraries changes its soname.
Though it seems like this might work in theory, I'm a little worried
about practical feasibility. It seems like if you have a library (say
libfoo) with several sub-library dependencies, you could fairly easily
get into a sitution where Debian's trying to get the upstream to bump
the soname because we want to include the new version of one of
libfoo's sub-libraries in Debian, while
RedHat/Mandrake/TurboLinux/SuSE's fighting that change because they
want the newest version of libfoo, but can't or don't want to update
the particular sub-library Debian's pushing for.
I guess a library could chose its soname (as mentioned previously)
based on a particular set of major versions of its sub-libraries at
configure time, but if you use sequential numbers, say 7 for
libgwrap-glib from gwrap-1.3 compiled against guile-1.4 and 8 if
libgwrap-glib is compiled against guile-1.6, then you're stuck if you
suddenly need to backward incompatibly change the gwrap API and still
want to build against both guile versions, not to mention that when
there are several sub-libs, i.e. the lib in question links against
libguile *and* libglib, you substantially constrain the build
environment when you hard code choices for versions of all of these
libs.
It also seems like hard-coding a set of soname choices for the
sub-libraries in the build envt gets even more complicated when the
library in question depends on several independently maintained
sub-libraries which will, of course, change sonames independently.
All that said, if there aren't any better solutions, I guess the above
concerns are mostly irrelevant for now, but I did want to make sure I
understood the potential issues.
Thanks
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: