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

[Daniel Eischen]

On Tue, 4 Sep 2007, Yar Tikhiy wrote:
>
> I tried to implement that in version_gen.awk and found that its
> error handling was rather weak.  Therefore I also improved its error
> handling and fixed a few other bugs.  Could you please review my
> changes?  They are in p4 and rev#1 corresponds to the version from
> the CVS repo:

I gave it a quick review, and it looked OK to me.  I haven't
tried using it.

> http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/user/yar/hack/share/mk/version%5fgen.awk
>
> And, I think now we can outline the plan for using SV in the fts(3)
> ABI change.
>
> 0. Goals:
> 	To provide CURRENT users with smooth experience before the
> 	next major release, when their tests and feedback are very
> 	important.
>
> 	To test drive our symbol versioning implementation and the
> 	newborn policy for its use.
>
> 	NOT to work around bugs in the build system -- they're being
> 	worked on under a different task guided by our make(1) guru
> 	Ruslan Ermilov.

Yes, and regarding that other mail, it's cool that it might
allow doing a cross target install ;-)

> 1. Commit:
> 	- The new versions of symbols are listed under FBSD_1.1
> 	  in the respective Symbol.map file.
> 	- The old versions are kept under FBSD_1.0 using
> 	  __sym_compat() directives, and they are listed
> 	  in src/lib/libc/ObsoleteVersions.
>
> 2. Release:
> 	In RELENG_7, the old versions are eliminated, which includes
> 	the following:
> 	- disconnecting the old implementation from the build
> 	  in src/lib/libc/gen/Makefile.inc;
> 	- deleting the old implementation in CVS: src/lib/libc/gen/fts-compat.*;
> 	- removing references to the old symbols from ObsoleteVersions.
>
> 3. HEAD cleanup:
> 	Half a year later the same removal procedure is applied to HEAD.
>
> Did I miss anything?

I don't think so.  I'm still not totally on-board with adding
fts_ in a new version FBSD_1.1.  It doesn't look like much is
affected by the fts change, but whatever...

> Oh, and we haven't decided on the format of ObsoleteVersions yet.
> What about using just the same symbol map format for it?

I think that's fine.  You might want to add some comments to it
(in C comment syntax?) above the set of symbols that points someone
at which files need to be modified or removed when the reaper comes
6 months later.  Maybe a date or something at when they're to be
removed?

-- 
DE