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

[Yar Tikhiy]

On Mon, Aug 27, 2007 at 09:47:31PM -0600, M. Warner Losh wrote:
> In message: <20070828023857.GW21352 at comp.chem.msu.su>
>             Yar Tikhiy <yar at comp.chem.msu.su> writes:
> : On Mon, Aug 27, 2007 at 09:30:48PM -0400, Daniel Eischen wrote:
> : > On Tue, 28 Aug 2007, Yar Tikhiy wrote:
> : > >
> : > >Example: Assume we released 7.0-R with all symbols at FBSD_1.0.
> : > >Before the 8.0 release cycle starts, struct FTS and struct FILE
> : > >change, perhaps a few times each, thus affecting the fts(3) and
> : > >stdio(3) global symbols.  At the very first change to a symbol or
> : > >their group, its 7.0-R variant is preserved at FBSD_1.0 and its
> : > >default version becomes FBSD_1.1.  Later changes to the current
> : > >variant of that symbol don't affect its version.  Consequently,
> : > >8.0-R is released with the new fts(3) and stdio(3) symbols at
> : > >FBSD_1.1, their 7.0-R variants at FBSD_1.0, and the rest of symbols
> : > >still at FBSD_1.0 because they are unchanged.  Let's note that
> : > >CURRENT users had to rebuild ports depending on fts(3) or stdio(3)
> : > >_each time_ an ABI component changed.
> : > 
> : > I think you're a little confused here.  CURRENT users did NOT have
> : > to rebuild ports when fts(3) or stdio(3) ABIs changed.  They
> : > would only have to rebuild if one of these ABIs changed _more
> : > than once between releases_.  That hasn't ever happened to my
> : > knowledge in the past, and it really shouldn't happen as long
> : > as things are tested and reviewed properly.
> : 
> : Oh, indeed!  If a user builds an ABI-dependent port before the
> : change, the port will record dependence on say fwrite at FBSD_1.0.  In
> : our example, the default version of fwrite() and friends will change
> : to FBSD_1.1 later, after 7.0-RELEASE is out, but fwrite at FBSD_1.0
> : will also stay as a compatibility version because it appeared in
> : the previous release.  Moreover, the port will still work even if
> : the ABI component changes once more after 8.0-RELEASE and proceeds
> : to FBSD_1.2, because fwrite at FBSD_1.0 will be there.  Similarly, a
> : port built between 7.0-R and 8.0-R will work after the 2nd change
> : as fwrite at FBSD_1.1 will be there, too.
> : 
> : I can't but remark that this is not a natural effect of symbol
> : versioning, but a consequence from the following policy:
> : 
> : - At most one new version is introduced between major releases.
> : - Symbol modifications during the period are assigned to the new version.
> : - There is exactly one change per symbol per version.
> : - All old symbol versions created so far are preserved.
> : 
> : Now we have at least one policy with known behavior. :-)
> 
> Or rather, isn't this just the consequences of the way the script that
> generates things works?

AFAIK, no.  The script isn't that restrictive although it's Daniel
who wrote it. :-) I think the script allows us to do almost anything
we can do with a plain vanilla version map.  It even supports multiple
version axes, which is used now to separate standard functions from
FreeBSD-specific functions.

-- 
Yar