On Fri, 24 Aug 2007, Warner Losh wrote:
From: Daniel Eischen <[EMAIL PROTECTED]>
Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h
Date: Fri, 24 Aug 2007 18:25:17 -0400 (EDT)
The other problem, once you get past the build tools, is now all your
ports binaries do not work. While people running current are big boys
and girls, it is a pain to have to frequently rebuild them.
I guess the build system should be more tolerant of this, but
there are bound to be problems regardless. I don't see why
the install tools can't also either have their own set of
libraries (utilizing LD_LIBRARY_PATH) or be built static.
I never added symbol versioning to libc in order to solve
-current upgrade problems. Sure, you're free to use it that
way, but it would not make me very happy ;-)
So who cares if we find new uses for tools? I never thought devd
would be used for network state transition...
What's the overhead of having the transition crutch around for a
while? The benefit is that people are less likely to screw up their
systems at a time when we want to encourage people to upgrade so they
can test the latest/greatest version. If it were 9 months after
RELENG_6 was branched, and a long time to a release, then I'd be much
more inclined to agree with the 'current is hard, so why spend
engineering effort on making it easy' crowd than I would now that more
of the world is watching and using it since we're in the glide path to
beta1.
I don't see why we can't put the versioned symbols in, let everybody
upgrade and then remove the old symbols after a big enough window has
passed. It isn't like they are hurting anything by being there, is
it?
If you are going to remove the interim versioned symbols, that's
OK with me, but what are you going to do for the people that miss the
transistion period (after the interim symbols are removed)? Shouldn't
the build system work regardless? If I understand correctly, I think
the more general problem is that the install tools are dependent on
working with new libraries.
If there is some actual harm here, it hasn't been clearly articulated
and needs to be if that's the case. I'm certainly open to this
possibility.
It should be easy to say FBSD_1.0 is RELEASE_7.0, FBBSD_1.1 is RELEASE_7.1,
etc. The versioned symbol namespace is mostly to aid the release
engineers. If you start to have FBSD_1.2, FBSD_1.3, and FBSD_1.4
are interim versions and FBSD_1.5 is release 7.1, that isn't good.
Again, I highly doubt you would have Sun or even Linux have interim
versions that are made public. If you want to have interim versions
and then remove them at a later point before a release, that is a
different story, but it doesn't solve the problem for someone missing
the transition period, whereas a more general solution would.
--
DE
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
