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

[M. Warner Losh]

In message: <200708270932.31208.jhb at freebsd.org>
            John Baldwin <jhb at freebsd.org> writes:
: On Saturday 25 August 2007 05:33:16 pm Ken Smith wrote:
: > On Sat, 2007-08-25 at 17:06 -0400, Daniel Eischen wrote:
: > > On Sat, 25 Aug 2007, Ken Smith wrote:
: > > 
: > > >
: > > > [ Not bothering to include references for the entire thread, go back and
: > > > read them if you really want to... ]
: > > >
: > > > I want Yar's work to proceed as planned please.  My reasons are:
: > > 
: > > No offense, but some things have been going in without being discussed
: > > an -arch or -current.  Approval for committing still has to go through
: > > re@, but that doesn't mean that changes shouldn't be vetted elsewhere
: > > prior to being sent to re@ approval.
: > > 
: > 
: > If that's the case then it's been my negligence and I apologize.  I'll
: > try to be more mindful of that moving forward.
: 
: The issue is that a plethora of symbol versions breaks our prior practice
: of limiting major bumps of shared libraries to 1 per release.

We're not talking plethora here.  We're talking a couple.  We're not
talking every change, but rather just the last one.  We're in exactly
the same position we'd be in after the release: bumping the symbol
version the first time a change is made to that symbol.

: Just as with
: shared libraries, we version the ABIs in releases and stable branches.
: We have _never_ versioned ABI changes in HEAD because HEAD is a tumultuous
: place and having the ABIs change multiple times in a branch w/o having
: multiple version bumps is just part of running HEAD.

We've never versioned ABIs in head because we've never had the ability
to do so in a non-disruptive way.  Also, this isn't the "wild west"
head of our forefathers.  We're not at some arbitrary point in the
evolution of FreeBSD, but in a code freeze getting ready to do a release.

: It should only affect
: developers because the vast majority of users are not running HEAD, so they
: just see 1 version bump and 1 ABI change when the new X.0 release is cut.

More folks than developers are running head these days.  Since we're
in the glide path to the release, lots of helpful users are testing
current towards that end.  Since it isn't just developers running
current at this stage, because we've asked a lot of people to try
current to see if their issues are corrected there, I think we should
use those tools that are easy to use to make their life less bumpy.

: Yar's changes should go in and before BETA1, but we don't need any compat
: hacks because the compat would be for users that we don't provide compat
: for.

ALL of Yar's changes should go in, including the versioned symbols.
Since the consequences of this ABI breakage are trivial to mitigate
with symbol versioning, we should do so.  We need a dry-run at it to
make sure there are no problems in the process.  We also should not
force all our testers right now to go through significant pain and
suffering.  They are much less likely to upgrade and continue to test
out new versions of current.  Rebuilding all the ports (since it is
hard to know which ones use fts) is hard and time-consuming (even on
my fast machines it takes days to rebuild everything exclusive of
ooo).

In short, I think this is the easiest solution to the build problems
that the change will cause given the set of users that are presently
using the head of the tree.  Hacking the build system to make the
incompatible change is dangerous and may break other upgrade paths
that are working.  Giving users explicit instructions for jumping the
gap would fix the intallworld case, but would still force users to
rebuild all their ports.  Adding the versioned symbols introduces a
tiny bit of cruft in the purity of the ABI, but solves the
installworld problem AND the rebuilding the ports problem.  Are there
other REAL solutions to the problem I've not considered?

Warner