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 _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"