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

[Yar Tikhiy]

On Mon, Aug 27, 2007 at 09:34:24PM -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. :-)
> 
> How is this a natural consequence of this policy?  If one were to
> bump twice, how would that break it?

If we bump a symbol twice or more times between a pair of major
releases while preserving its older versions for compatibility,
we'll have to decide what to do with the intermediate versions
later.  If we keep them forever in the same manner as released
versions are going to be kept, CURRENT users will be able to use
ports built any time, exactly as in the above case.  But, with a
lot of such unreleased versions accumulated in the library, their
support can need considerable efforts, e.g., if a security hole in
all versions of the symbol is found.  Perhaps we'll have to prune
away the oldest unreleased versions periodically, but then some
people will have to rebuild their old ports.  Not a big deal, but
the smoothness is lost to some extent.

OTOH, if we bump a symbol twice or more times but preserve only its
last released version, some people will have to rebuild some ports
after the second and later bumps, namely ports built against an old
intermediate version of the symbol, which we chose not to preserve.

BTW, here are three more policies and their properties. :-)

-- 
Yar