John Baldwin wrote:
On Friday 26 October 2007 12:00:54 pm Ken Smith wrote:
On Fri, 2007-10-26 at 11:41 -0400, John Baldwin wrote:
On Friday 26 October 2007 10:53:47 am David O'Brien wrote:
On Thu, Oct 25, 2007 at 05:31:03PM -0400, Ken Smith wrote:
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
This is news to me.
I've never heard that we're that concerned with forward compatability
even on a RELENG branch. We do not break the ABI for backwards
compatability - in that everything (including kernel modules) that ran on
6.2 must run on 6.3.
Agreed. The solution to the shared /usr/local problem is to use the oldest
version for /usr/local. That has always been the case. Forwards
compatiblity (what you are asking for) is significantly harder to guarantee
since accurately predicting the future isn't much a science.
Yeah, sorry. I guess I've been a bit grumpy the past couple days and
over-stated the "*absolutely* *necessary*" part above. It should have
read "*necessary*", not "*absolutely* *necessary*".
I'd just like us to question if it's necessary here. Is there a good
enough way to do this without causing the breakage? I sorta liked
Warren's question. Does this stuff need to be inlined and if not would
that solution avoid the breakage?
I can agree that in this instance it would be nice to keep RELENG_7 and HEAD
from diverging too much right now. I was more concerned about there being a
new general policy. Are you really sure you want forwards compat and not
just backwards compat ABI?
Our users rely on it, namely the ability to run newer packages compiled
against 6-stable on a 6.2-RELEASE system. This is not guaranteed to
always work but should not be broken without extremely good reason.
Kris
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
