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

[John Baldwin]

On Saturday 25 August 2007 01:06:37 am Yar Tikhiy wrote:
> On Fri, Aug 24, 2007 at 06:25:17PM -0400, Daniel Eischen wrote:
> > I never added symbol versioning to libc in order to solve
> > -current upgrade problems.  Sure, you're free to use it that
> > way, but it would not make me very happy ;-)
> 
> You put it as though symbol versioning is your area of interest and
> you just don't want any intruders to tamper with it.  It wouldn't
> have seemed so if there had been a well-defined policy on symbol
> versioning usage somewhere on www.freebsd.org.

No, there isn't a well-defined policy currently, feel free to write it
down. :)  What Dan is saying is that symbol versioning should follow the
same de facto policy used prior to symbol versioning for managing shared
library major numbers which is: only bump once during HEAD even if you
have multiple ABI changes.  Otherwise you can stifle work on HEAD as
people will have to provide compat every time they change an ABI in HEAD
even if they change it 3 or 4 times before the X.0 release.   HEAD only
needs to retain compat for earlier RELENG_x, it has never and should not
contain compat for older HEAD except as temporary hacks.  You also have
the issue of adding a lot more compat clutter to the libraries if we
support compat for every ABI change that ever happens in HEAD.

In this case using a fbsd.hack symbol version for the old fts(3) symbols
won't work, the existing binaries are already linked against fbsd-1.0,
but the new fts(3) routines should be fbsd-1.0 as fbsd-1.0 is already
a version bump from RELENG_6 (libc.so.6 and no symbol versions).

-- 
John Baldwin