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

[John Baldwin]

On Monday 27 August 2007 01:10:14 pm Daniel Eischen wrote:
> 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).

Actually, what we have now with fts(3) is exactly this: two versions of the 
symbols that wish to be called fbsd_1.0.  By using a late binding of 
the "official" fbsd_X.0 version we can avoid that.  It also provides a way to 
delineate ABI changes that aren't visible to releases and -stable branches.  
They will exist in HEAD with only having a fbsd-current symbol, so they can 
be axed from HEAD safely.

> 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.

You don't have to remove the compat shims from HEAD right away.  Remember, 
release is on a _branch_: RELENG_X.  You remove the compat shims from the 
branch before the release, but you can use discretion as to when you
actually remove them from HEAD.

-- 
John Baldwin