Date: Tue, 28 Aug 2007 12:37:36 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: "M. Warner Losh" <imp@bsdimp.com> Cc: src-committers@freebsd.org, jhb@freebsd.org, peterjeremy@optushome.com.au, alfred@freebsd.org, cvs-all@freebsd.org, deischen@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h Message-ID: <20070828083736.GX21352@comp.chem.msu.su> In-Reply-To: <20070827.213424.1678771352.imp@bsdimp.com> References: <20070828004842.GT21352@comp.chem.msu.su> <Pine.GSO.4.64.0708272127371.28508@sea.ntplx.net> <20070828023857.GW21352@comp.chem.msu.su> <20070827.213424.1678771352.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 27, 2007 at 09:34:24PM -0600, M. Warner Losh wrote: > In message: <20070828023857.GW21352@comp.chem.msu.su> > Yar Tikhiy <yar@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@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@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070828083736.GX21352>