Re: Possible library versioning approach -- (evaluation requested)
Junichi Uekawa <dancer@netfort.gr.jp> writes:
> It would make package names very much longer.
> People already complain about package names containing the full soname.
Good point. I wonder if within debian, we could just name the
packages after some sequential "debian number" that only changed when
either the upstream API or the library dependencies changed. So in
debian we might have:
Pkg libgwrap-glib-deb1 - which contains libgwrap-glib-2-0-guile-9.so
and then when we decide to migrate to libguile12 and recompile this
library, we'd bump the debN number:
Pkg libgwrap-glib-deb2 - which contains libgwrap-glib-2-0-guile-12.so
We could then just bump the debN version whenever we needed to, and
older versions of libraries would be handled in exactly the same way
that older versions of libs are now.
> It would be nice to have a generic m4 script dumped into autoconf
> if it is going to be recommended, which will try link binaries
> and objdump it and concatenate all the NEEDED fields of
> such binary, to generate the required portion of the soname.
That *would* be quite interesting, though there might be some argument
for only putting the sub-library names and versions into a library
soname for the "relevant" sub-libraries. i.e. if you're a library
that is only using an API from some sub-library that doesn't export
complex types (structs, etc.), or if you don't propagate those types
out via your own API, or pass them to other sub-libraries, then I
suspect you may not need to put that sub-library's name/version into
your soname.
However, even if the above is true, then it would still be interesting
to provide infrastructure to allow people to easily compute and embed
the names/versions for those relevant sub-libs. i.e. perhaps we could
provide
libfoo_la_RELEVANT_SUB_LIBS := glib guile
and let libtool and/or automake do the rest.
> Note that this method has been recommended by libapt-pkg and
> libstdc++ but not many other projects have taken it up, because this
> creates so many different versions that it is almost impossible to
> keep cross-distribution binary compatibility.
Though if (as suggested above) people only put the sub-lib versions
and sonames into a library soname for the relevant sub-libs, it seems
like the number of different versions you'd get would be exactly the
number you'd need if you actually want your code to work right :>
--
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: