Adrian Bunk <b...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9uzmsx3.fsf...@windlord.stanford.edu