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

[Daniel Eischen]

On Tue, 28 Aug 2007, John Baldwin wrote:

> On Tuesday 28 August 2007 01:18:38 pm Daniel Eischen wrote:
>>
>> The only thing I would add is that we can do this by using the
>> real public versions in -current instead of private ones only
>> seen in current.  By using the public versions, -current users
>> will never have to rebuild any of their ports _unless_ the
>> same ABI changed more than once in -current, and that has
>> never happened in the past.  If it does happen, you can
>> remove interim versions from RELENG_X at the branch, and
>> then remove the interim version from -current some time later.
>> This is the same approach as using a "private in current"
>> version namespace.  The only disadvantage is that you might
>> be missing a version or two in RELENG_X if you remove an
>> interim FBSD_1.4 for instance.
>
> Yes, but how do you know which ones are interim versions that are safe to be
> removed?  Having separate namespaces makes this clear.

Any symbol in the Symbol.map files (or the generated Version.map)
that is duplicated from the point at which -current was last
branched.

If you go with my approach and only create one new version in
-current, then it will be more obvious because the symbol(s)
will already exist in -current's one and only version.  That
will force us to decide whether we should force a rebuild or
just make a new version - it could be on a case by case basis
if it ever happened.

But even with the other approach (each ABI change creates a
new version), you could write a script to find all the versions
with duplicate symbols.  I suppose you could even have it
generate an ObsoleteVersions file that gets committed along
with the most recent ABI change.

-- 
DE