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

[John Baldwin]

On Monday 27 August 2007 09:56:25 am Pawel Jakub Dawidek wrote:
> On Mon, Aug 27, 2007 at 08:50:19AM -0400, John Baldwin wrote:
> > On Friday 24 August 2007 07:22:12 pm Warner Losh wrote:
> > > What's the overhead of having the transition crutch around for a
> > > while?  The benefit is that people are less likely to screw up their
> > > systems at a time when we want to encourage people to upgrade so they
> > > can test the latest/greatest version.  If it were 9 months after
> > > RELENG_6 was branched, and a long time to a release, then I'd be much
> > > more inclined to agree with the 'current is hard, so why spend
> > > engineering effort on making it easy' crowd than I would now that more
> > > of the world is watching and using it since we're in the glide path to
> > > beta1.
> > > 
> > > I don't see why we can't put the versioned symbols in, let everybody
> > > upgrade and then remove the old symbols after a big enough window has
> > > passed.  It isn't like they are hurting anything by being there, is
> > > it?
> > 
> > Then why didn't we bump libc multiple times in a branch?  It's the same
> > exact thing except more fine-grained.  If it's ok to bump symbol
> > versions multiple times (remember, we've already done 1 bump by adding
> > versioning and going to libc.so.7) in a branch, then it should have been
> > ok to bump libc major numbers multiple times.
> > 
> > I agree with Dan that we are trying to build releases, and folks running
> > -current are expected to tolerate change during the current branch.
> 
> Folks running -current are also committers that use -current to test as
> much as they can, but also to use it for day-to-day work. Isn't it why
> we have perforce and other policies, so that -current can be stable and
> usable? If we have tools that can help -current users to use the system
> smoothly, I'm all for using them. I can't imagine taking yet another two
> days and reinstalling all ports, just because -current users are not
> important. Of course -current users know how to deal with things like
> this, but that doesn't mean they have to if there is another way.
> The more surprises like that one, the less -current users we will have,
> which means the less testing.
> If there will be a need for me to reinstall all the ports I'll choose
> not to upgrade or downgrade to 6.x...

My desktop and server at home run 6.x.  Only my laptop and test machines
run -current, and of those, only my laptop has a lot of ports and I just
rebuild all the ports when I upgrade it over an ABI change.  Test boxes
for things like mysql, etc. don't necessarily need all of X or KDE, etc.
installed, so rebuilding the ports on a test box generally shouldn't have
but so much overhead.

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.

You could even proactively drop older fbsd-current-* compat  shims in HEAD
after having them around for a while.

-- 
John Baldwin