cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h
jhb at freebsd.org
Mon Aug 27 10:36:28 PDT 2007
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.
More information about the cvs-src