Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Aug 2007 16:56:24 -0400
From:      Coleman Kane <cokane@FreeBSD.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Daniel Eischen <deischen@freebsd.org>, Yar Tikhiy <yar@comp.chem.msu.su>, src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org
Subject:   Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h
Message-ID:  <46CF45F8.9060405@FreeBSD.org>
In-Reply-To: <200708241635.36266.jhb@freebsd.org>
References:  <200708230509.l7N59VCi048341@repoman.freebsd.org> <Pine.GSO.4.64.0708241057010.12450@sea.ntplx.net> <20070824183630.GA99474@comp.chem.msu.su> <200708241635.36266.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> On Friday 24 August 2007 02:36:30 pm Yar Tikhiy wrote:
>   
>> On Fri, Aug 24, 2007 at 11:03:12AM -0400, Daniel Eischen wrote:
>>     
>>> On Thu, 23 Aug 2007, Yar Tikhiy wrote:
>>>
>>>       
>>>> yar         2007-08-23 05:09:31 UTC
>>>>
>>>> FreeBSD src repository
>>>>
>>>> Modified files:
>>>>   lib/libc/gen         fts-compat.c fts-compat.h
>>>> Log:
>>>> Forced commit to note repo-copy:
>>>>
>>>> These files have been repo-copied from src/include/fts.h
>>>> and src/lib/libc/gen/fts.c to serve as a base for 4.4BSD
>>>> compatible versions of fts(3) functions to be preserved
>>>> through libc symbol versioning while the default versions
>>>> undergo ABI-breaking extension to support big file trees.
>>>>         
>>> When are you going to break the ABI?  After 7.0 is tagged
>>> and released?  If you break the ABI before, you don't need
>>> or want to have the compat versions; the libraries have already
>>> been bumped in prep for release.  I don't think we want to
>>> use symbol versioning as a crutch for -current users; the
>>> version definitions are meant for public releases only.
>>>       
>> The reason for exercising symbol versions right now is that "make
>> installworld" is sensitive to the fts(3) ABI.  If the ABI is just
>> broken w/o special measures, "make installworld" will fail in the
>> middle and leave you with a botched system.  It goes as follows:
>>
>> - "make installworld" copies the old /usr/bin/find and some other
>>   tools to /tmp/install.xxx for use during the install
>> - libc is overwritten by its new instance, with new fts(3) ABI
>> - the old find(1) is run by installworld and dumps core immediately.
>>
>> Earlier the problem was to be avoided by bumping libc version so
>> that the old libc is kept, and now I chose symbol versioning to get
>> around it.  Do you think there is a different way?
>>     
>
> 6.x users upgrading to 7.0 will have a 6.x /usr/bin/find, so they will
> be ok.  It's only old -current users who already have a libc.so.7 that
> will be inconvenienced, and that's part of running -current.  Maybe
> you could use a hack where for 7.x osreldate's you copy tools out of
> /rescue instead for a few weeks to give people on -current a chance to 
> upgrade.
>   
Whatever the solution turns out to be, don't forget to drop it into 
UPGRADING...

--
Coleman Kane



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46CF45F8.9060405>