cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h
deischen at freebsd.org
Tue Aug 28 13:15:30 PDT 2007
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
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.
More information about the cvs-src