Date: Fri, 26 Oct 2007 09:46:52 +0800 From: "Rong-en Fan" <grafan@gmail.com> To: "Ken Smith" <kensmith@cse.buffalo.edu>, "Scott Long" <scottl@samsco.org> Cc: Andrey Chernov <ache@nagual.pp.ru>, src-committers@freebsd.org, d@delphij.net, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/lib/libc/locale utf8.c Message-ID: <6eb82e0710251846j3542972q61712ba8a4b3ff7@mail.gmail.com> In-Reply-To: <1193347863.93167.11.camel@neo.cse.buffalo.edu> References: <200710150951.l9F9pUm7026506@repoman.freebsd.org> <4720B30F.4040903@samsco.org> <20071025151707.GA11398@nagual.pp.ru> <4720E0AF.1010004@samsco.org> <4720E904.2090704@delphij.net> <4720EA15.40002@samsco.org> <20071025191437.GD16187@nagual.pp.ru> <1193347863.93167.11.camel@neo.cse.buffalo.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/26/07, Ken Smith <kensmith@cse.buffalo.edu> wrote: > On Thu, 2007-10-25 at 23:14 +0400, Andrey Chernov wrote: > > On Thu, Oct 25, 2007 at 01:10:13PM -0600, Scott Long wrote: > > >> Well, I think the problem is not exposing a new symbol by itself, but > > >> __mb_sb_limit is being used in _ctype.h, in a form of __inline > > >> functions. Therefore, the change will break new binaries running on > > >> older systems. Personally I think this is acceptable, but maybe we > > >> could have a better way to avoid this, because the binaries are no > > >> longer backward compatible (i.e. you may have trouble running a program > > >> compiled for 6.3-RELEASE on 6.2-RELEASE, if it uses locale bits). > > > > > > If this is true, then it directly violates the API/ABI compatability > > > guidelines that were developed and agreed to by the project in 2005. > > > > We define only backward compatibility, not forward one. Do you f.e. expect > > to run 7x binaries on 6x as is? At least compat7x required (if all syscall > > are the same). > > > > That's not what Scott was referring to. > > It's expected that 8.X binaries *may* not run on 7.X without compat > libraries or something along those lines. That said this sort of > breakage is what I was hoping we could avoid having happen before 7.0 > was out the door (it's what I meant by asking people to be a bit > conservative until we're done with 7.0) because it does tend to add to > peoples' general frustration level at a time there is enough stress > coming from other sources. > > What we need to try and avoid unless *absolutely* *necessary* is the > part Scott quoted above - binaries compiled on 6.3-REL should work on > 6.2-REL unless there was a really big issue and the solution to that > issue required us to break that. The reason is simple, people should be > able to continue running 6.2-REL "for a while" and still be able to > update their packages from packages-6-stable even after portmgr@ starts > using a 6.3-REL base for the builds (I think they use RELENG_6 for the > most part but I could be wrong). And this sort of backwards > compatibility is a big help to large sites that do things like have an > NFS server where local software gets installed (we build stuff and stick > it in /util/bin which is NFS mounted from one machine). Its a big help > running a site like this if all machines don't need to be at exactly the > same OS rev as the server. I will work with delphij and try to find a solution. Thanks, Rong-En Fan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6eb82e0710251846j3542972q61712ba8a4b3ff7>