|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Wed, 31 May 2017 17:00:24 -0500 From: Will Fiveash <will.fiveash@oracle.com> To: Simo Sorce <simo@redhat.com> Message-ID: <20170531220024.GA25005@oracle.com> Mail-Followup-To: Simo Sorce <simo@redhat.com>, Greg Hudson <ghudson@mit.edu>, Andreas Schneider <asn@samba.org>, MIT Kerberos Dev List <krbdev@mit.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1496248839.929.34.camel@redhat.com> Cc: MIT Kerberos Dev List <krbdev@mit.edu> Content-Type: text/plain; charset="iso-8859-1" Errors-To: krbdev-bounces@mit.edu Content-Transfer-Encoding: 8bit On Wed, May 31, 2017 at 12:40:39PM -0400, Simo Sorce wrote: > On Wed, 2017-05-31 at 11:53 -0400, Greg Hudson wrote: > > The real reason I followed up was to ask a question about the libkrb5 > > soname. > > > > For libkadm5clnt, libkadm5srv, and libkdb5, we install a header file > > with a comment noting that the API isn't stable, but we do change the > > library soname (via LIBMAJOR in Makefile.in) each time we make > > incompatible changes to the ABI. > > > > For libkrb5, we haven't changed the soname in a long time; it has > > sat at libkrb5.so.3 since release 1.2. My hazy understanding is > > that changing the soname would impose a moderate maintenance cost on > > downstream distributions, but I don't know the magnitude of that > > cost. > > For a foundational library like libkrb5 which is linked in a lot of > software I would define the cost high, it basically requires a rebuild > of all dependent code, and it mans incompatibility with existing > binaries, which may or not be rebuildable (source code not always > available or FTBFS issues may arise). I agree with Simo, please do not change the soname of libkrb5. > > So if we do install a header file prototyping some semi-public > > libkrb5 functions, and later change them, do we plan to bump the > > library soname? > > Well, in theory if you change exposed symbols you should, independently > of whether there are header files or not. > That said, if this is a private API, marked as so, I do not see why you > would bump the soname. I would though, change the symbol name, and > either maintain a compatibility symbol or have the header use some > dload() trick to check if the symbol is available and gracefully fail > if not. Also agree with Simo's suggestions. Backwards runtime compatibility is a big deal for Solaris. For private APIs, if they change then we can rebuild the internally delivered binaries that have a dependency on those interfaces but because we do not want to force customers/third parties to recompile binaries depending on public APIs Simo's advice above is what I also recommend. > > If we do, it imposes some cost; if we don't, I think it basically > > means the Samba package breaks if you upgrade libkrb5, which a > > downstream distribution might not want to tolerate. > > This can be handled in other ways: > - symbol versioning > - dload() tricks > - let distributions care for it > - provide a stable wrapper you are ok exposing in the public API/ABI -- Will Fiveash Oracle Solaris Software Engineer _______________________________________________ krbdev mailing list krbdev@mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |