Date: Thu, 25 Oct 2007 17:31:03 -0400 From: Ken Smith <kensmith@cse.Buffalo.EDU> To: Andrey Chernov <ache@nagual.pp.ru> Cc: cvs-src@FreeBSD.org, Scott Long <scottl@samsco.org>, src-committers@FreeBSD.org, d@delphij.net, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/locale utf8.c Message-ID: <1193347863.93167.11.camel@neo.cse.buffalo.edu> In-Reply-To: <20071025191437.GD16187@nagual.pp.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
--
Ken Smith
- From there to here, from here to | kensmith@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1193347863.93167.11.camel>