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

[Yar Tikhiy]

On Tue, Aug 28, 2007 at 12:37:36PM +0400, Yar Tikhiy wrote:
> 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:
> > : 
> > : 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.

Another caveat of these two policies came to my mind.  What to do
with the old intermediate versions of symbols when the next RELENG_X
is branched?  For pure STABLE and RELEASE users they are nothing
but dead code, so it would make sense to remove them from the branch.

OTOH, dropping them will create a pain for those who gets tired of
CURRENT and decides to take a turn to the new STABLE branch because
ports linked against the dropped versions will need a rebuild.  But,
upon a second thought, so we'll bind such people to CURRENT forever
and prevent their desertion. :-)

-- 
Yar