On Tue, 2008-05-27 at 16:21 -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Maxim Sobolev wrote: > | Xin LI wrote: > |> delphij 2008-05-27 20:04:27 UTC > |> > |> FreeBSD src repository > |> > |> Modified files: (Branch: RELENG_6) > |> include string.h lib/libc/string > |> Makefile.inc memchr.3 sys/sys param.h Added > |> files: (Branch: RELENG_6) > |> lib/libc/string memrchr.c Log: > |> MFC: Add memrchr(3). > | > | I think this is not very good idea to MFC that into stable releases 6.x > | and 7.x. The reason is that configure scripts for some packages might > | detect up this API and enable it. Which means that some binary-only > | packages build for say 6.4 won't work on 6.3 and down. AFAIK, both > | forward and backward compatibility is required (or at least desired?) > | for stable branches. > | > | While it's "nice-to-have" feature, I see no pressing need to MFC this > | interface. > > I don't think so, perhaps I am wrong, but do we really want absolutely > no *new* features on -STABLE branches? I think this case is different > from ctype(3) fix which is widely used API and a change of existing > interface by adding new dependency to a symbol that is not exist in the > older FreeBSD releases. It will really scare me away from any new > features if we can not add an new interface in RELENG_* trees even if > they have no outside dependencies, if that's the policy of ABI > compatibility guidelines then I'd be happy to revert these MFC's, but > having something can only run on -CURRENT does not sound like a good > idea, and maintaining in-tree alternative patches for different branches > for such things is really painful and will likely reduce the lifespan of > given -STABLE branches, is these our goal and should be kept in mind > when maintaining code in RELENG_* branches?
I'm inclined towards letting this stay in. The ctype(3) fix altered an
existing interface in a way that made it incompatible with older stuff.
This is adding new stuff.
The "forwards compatibility" is a good thing for people trying to use
pre-built packages on older systems but this one is a case of us trying
to avoid breakage that, if it were to occur, would be at the whims of
the configure script for the packages. I think that's pushing the
notion of forwards compatibility a tiny bit too far.
--
Ken Smith
- From there to here, from here to | [EMAIL PROTECTED]
there, funny things are everywhere. |
- Theodore Geisel |
signature.asc
Description: This is a digitally signed message part
