[OpenAFS-devel] open issues for an openafs 1.8 branch

[Benjamin Kaduk]

On Mon, 29 Sep 2014, Garrett Wollman wrote:

> <<On Mon, 29 Sep 2014 12:08:07 -0400, chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> said:
>
> > Has OpenAFS ever been installed with shared libraries by any of the
> > packaged installers?  If not, I don't see a reason to bump the
> > numbers.  That said, if the API is changed (and changed in a
> > non-backward compat way) we of course need to bump the numbers.  I
> > would comment that adding a symbol is changing the API and seems like
> > it should require an increment.
>
> No.  That's not how ELF version numbers work.  An ELF shared library
> version number should never be changed except when an existing symbol
> is either redefined (in a way that breaks binary compatibility) or
> removed.  And in either case, you should be using symbol versioning so
> that they shared library version still doesn't change.
>
> This is demonstrably difficult for a project the size of OpenAFS to
> accomplish; a seemingly minor change to a type or a function's
> signature may break binary compatibility in non-obvious ways.  But
> that's how it's supposed to work, in any event.

The particularly exciting feature about roken is that we have little
control over when symbols get *removed*.  Since a no-change rebuild of
openafs on a newer OS might not need to provide as many symbols.

This probably means that we should strongly discourage any components from
outside of openafs from using librokenafs (which we do, by virtue of not
installing headers), and require that all installed openafs components are
the same version [as the librokenafs installed].

-Ben