cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h

[Daniel Eischen]

On Mon, 27 Aug 2007, John Baldwin wrote:
>
> Perhaps a more useful discussion would be how can we use symbol versioning
> sanely to support this in the future?  The fbsd.hack idea could work, but
> it doesn't work in this case because the existing binaries are already
> linked.  One suggestion that could start with 8.0 could be this:
>
> - when bumping the version for a symbol in HEAD, instead of going from
>  fbsd-X.Y to fbsd-X+1.0, put the new symbol as fbsd-current-X+1.0.  You
>  can keep bumping the symbol as fbsd-current-X+1.whatever for subsequent
>  changes
> - when it's time to branch HEAD to RELENG_X+1, you then add fbsd-X+1.0
>  symbol versions for the current versions of all the bumped symbols, and
>  remove all the fbsd-current-* versions and compat shims before the
>  release (before the RELENG_X+1_0 branch in fact).  The rule there being
>  that no release should ever ship with visible fbsd-current-* symbol
>  versions.

I don't think you need intermediate symbol versions, one should be
sufficient.  The problem would only arise if you make an ABI change
to a function or set of functions that have already had an ABI change
in the current version.  For example, if there were a function
ftsfwrite(FTS, FILE *, ...), and you make the version bump from
FBSD_1.0 to FBSD_1.1 when FTS changes, then if FILE changes, you
need to bump FBSD_1.1 to FBSD_1.2.  If there are no overlapping
changes in the ABI, you can continue to add newly changed symbols
to the current version (in this case FBSD_1.1).

How may times have we ever had overlapping ABI changes in the past?
Have we ever?  It's not worth fiddling with intermediate symbols,
because with that method you're still forcing -current users to
rebuild everything just before or after RELEASE to get the final
symbols (when the intermediates are removed).  If there are no
overlapping ABI changes, then no one has to rebuild any ports.

-- 
DE