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

[Alfred Perlstein]

Sorry for top posting, but...

I agree very strongly with Warner, in short, if possible, reducing the
number of major gotchas of running current will make our developer
and early adopters a lot happier.

It will help FreeBSD.

One of the things that turns me off to FreeBSD is the feeling that
I get that certain people take some kind of pride in forcing users
to go through dangerous and complex hoops in order to run current.

It shouldn't be so if the overhead of making it easier is so small.

-Alfred

* M. Warner Losh <imp at bsdimp.com> [070827 07:59] wrote:
> 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

-- 
- Alfred Perlstein