Date: Tue, 28 Aug 2007 16:15:16 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: src-committers@freebsd.org, Yar Tikhiy <yar@comp.chem.msu.su>, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h Message-ID: <Pine.GSO.4.64.0708281600430.3757@sea.ntplx.net> In-Reply-To: <200708281403.05931.jhb@freebsd.org> References: <200708270850.20904.jhb@freebsd.org> <200708281142.07941.jhb@freebsd.org> <Pine.GSO.4.64.0708281256150.3757@sea.ntplx.net> <200708281403.05931.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Aug 2007, John Baldwin wrote: > On Tuesday 28 August 2007 01:18:38 pm Daniel Eischen wrote: >> >> The only thing I would add is that we can do this by using the >> real public versions in -current instead of private ones only >> seen in current. By using the public versions, -current users >> will never have to rebuild any of their ports _unless_ the >> same ABI changed more than once in -current, and that has >> never happened in the past. If it does happen, you can >> remove interim versions from RELENG_X at the branch, and >> then remove the interim version from -current some time later. >> This is the same approach as using a "private in current" >> version namespace. The only disadvantage is that you might >> be missing a version or two in RELENG_X if you remove an >> interim FBSD_1.4 for instance. > > Yes, but how do you know which ones are interim versions that are safe to be > removed? Having separate namespaces makes this clear. Any symbol in the Symbol.map files (or the generated Version.map) that is duplicated from the point at which -current was last branched. If you go with my approach and only create one new version in -current, then it will be more obvious because the symbol(s) will already exist in -current's one and only version. That will force us to decide whether we should force a rebuild or just make a new version - it could be on a case by case basis if it ever happened. But even with the other approach (each ABI change creates a new version), you could write a script to find all the versions with duplicate symbols. I suppose you could even have it generate an ObsoleteVersions file that gets committed along with the most recent ABI change. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0708281600430.3757>