Re: CURRENT && /usr/ports

On Thu, 26 May 2011, Kostik Belousov wrote:

> On Thu, May 26, 2011 at 12:47:53PM -0400, Daniel Eischen wrote:
>> On Thu, 26 May 2011, Kostik Belousov wrote:
>>
>>> On Thu, May 26, 2011 at 10:16:15AM -0400, b. f. wrote:
>>>> Matthias Apitz:
>>>> ...
>>>>> I'm running -CURRENT on my laptop (r220692 from ~mid of April) and
>>>>> /usr/ports from CVS from the same day; I want from time to time (let's
>>>>> says once a week) SVN update my kernel and userland; I know that these
>>>>> two should be in sync, but what about the ports? I have installed around
>>>>> 1200 ports I'm used to use. Is there any special note in
>>>>> /usr/src/UPDATING
>>>>> when the ABI changes and would break the compiled ports?
>>>>
>>>> There is a lot of relevant information in UPDATING, but this file
>>>> doesn't focus on ports, and some changes that affect ports aren't
>>>> mentioned. You can find some workarounds or IGNORE settings in
>>>> individual port Makefiles based upon OSVERSION, some open PRs which
>>>> describe known problems (and, occasionally, solutions), and a partial
>>>> list of problems at:
>>>>
>>>> http://wiki.freebsd.org/PortsBrokenOnCurrent
>>>>
>>>> (but this last listing is somewhat incomplete and out-of-date). You
>>>> can also find build logs at:
>>>>
>>>> http://pointyhat.freebsd.org/errorlogs/
>>>>
>>>> Efforts to find and fix these problems will accelerate after the
>>>> slush/freeze that will precede the release of FreeBSD 9.
>>>
>>> [With the re hat on]
>>>
>>> The policy that we are trying to follow with regard to the userland ABI
>>> in the project is that
>>> - the libraries that already provide symbol versioning shall not break
>>> ABI backward-compatibility under any circumstances. The list of such
>>> libraries includes libc, libpthread, libm and libstdc++. There are other
>>> libraries that also implement symbol versioning, but they are supplied
>>> by third parties, and we rely on the upstream projects to not break
>>> the guarantee (mostly).
>>
>> To clarify a bit, FreeBSD versioned libraries (libc, libpthread, etc)
>> in HEAD will not break the ABI with prior releases.  But within
>> different versions of HEAD, there may be ABI breakages.  For instance,
>> if we break the ABI for foo() once in head on April 20, 2011, then
>> we provide a compatible symbol for foo() in RELENG_8.  If on May 26
>> 2011 we decide that the ABI for foo() needs to be broken again,
>> then we do not force ourselves to provide a compat symbol for foo()
>> between April 20 and May 26.  Depending on the breakage, we may
>> provide a April 20 - May 26 compat symbol as a temporary aid
>> for folks running HEAD, but at some point before HEAD is branched
>> it will be removed.
>>
>> The case of this happening should be very rare, and I don't think
>> it has happened yet.
>
> My POV is that we shall always keep backward ABI compatibility for
> the versioned libraries. In the case you mentioned, it is much safer
> to provide the shims. Among other reasons, if intermediate change get
> merged (after the final change landed in HEAD), then next major release
> simply cannot be made ABI-compatible with the previous one.

If the intermediate case gets merged, then yes we will always have
to keep the compat symbol for that version.  But when we break the
ABI, we will be (or should be) very aware of it when merging.  We
wouldn't intentionally merge an intermediate ABI.

-- 
DE