Bug#692155: CUPS shared library issue
Adrian Bunk <bunk@stusta.de> writes:
> Having a SONAME for such a library would cause other problems, e.g. the
> changes cherry-picked into 1.5.2-8 (that caused #668662) could result in
> a private library whose ABI would not match any upstream SONAME.
> Not an unsolvable problem (one could even automatically encode version
> and Debian revision into the SONAME), but also not much nicer than the
> status quo.
The main advantage over the status quo is that the non-public API wouldn't
be an attractive nuisance. I don't know if this has ever happened with
CUPS, but with, for example, the Kerberos libraries, we've had problems in
the past where exported but internal and undocumented symbols were used by
some applications, which then broke when those symbols changed or
disappeared. It's almost inevitable that happens sooner or later if
there are any symbols exposed from a shared library that aren't part of
the public API.
Tight symbol discipline is probably the primary thing that one can do as a
shared library author to make shared libraries more robust.
All that being said, there's probably no point in debating it within
Debian since it's the sort of thing that upstream would need to make the
call on.
> Creating a libcupsprivate that is a static library (which also has it's
> drawbacks) might be another approach for an upstream to solve this
> problem.
This will only work if it doesn't need access to shared data maintained in
the shared library (as you probably know). I'm not sure how complex of a
library this is; if it just has function implementations with nothing
complex like thread-local storage or global data manipulated by the shared
library, this can work. (Libtool makes this fairly easy to do via a
convenience library, in fact. I do this with my shared utility library
for all the software I maintain.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: