[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Possible library versioning approach -- (evaluation requested)

One of the main approaches that has been suggested to handle
versioning a lib that depends on sub-libs is to just have a given
version of the lib *require* a particular set of versions of the
sub-libs, and then refuse to build against anything else.  An
alternate approach was to choose the soname for the lib at configure
time based on a lookup table of sets of sub-lib sonames.

The first approach appears untenable in cases where your lib can and
*must* support several versions of some of the sub-libs.  There is no
"one set of versions" that you can pick and enforce.  In the
libgwrap-glib and gnucash case, this is true because gnucash (partly
because of RH) must support guile 1.3.4, 1.4, and 1.6.

The second approach above, using a table like this to pick the soname:

    glibversion  guileversion  gwrap-glib-1-soname
       1.2          1.4               1
       1.2          1.6               2
       2.0          1.4               3
       2.0          1.6               4

will cause the lib to chew through sonames in a big hurry (N more
sonames with each upstream API change, where N=number-of-rows), and
also means that the sequential ordering of sonames doesn't really mean
anything wrt the progression of the API.

So I'm wondering whether or not the following approach would be
considered acceptable, or not.  (i.e. does it pass the smell test).
First, name the library according to the changes in the API that would
normally be indicated by the number in the soname, and then choose the
soname based on a lookup table like the above.  So the soname would
reset to 0 each time you release a new version of the API, i.e. you'd
eventually have, libgwrap-glib-1, libgwrap-glib-2, and
libgwrap-glib-3, and within each series of libgwrap-glib-N releases,
for a given N, you'd pick the soname at configure time *only* to
indicate the "signature" of library versions it is linked against

    glibversion  guileversion  gwrap-glib-1-soname
       1.2          1.4               1
       1.2          1.6               2
       2.0          1.4               3
       2.0          1.6               4

and you'd create a new table (if needed) for gwrap-glib-2, etc.

Of course it'd be a little unexpected to have a libname like libfoo-1
whose soname isn't necessarily 1, but that doesn't seem like too big
an issue to me so far...

TIA for any help.

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: