cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h

[M. Warner Losh]

In message: <Pine.GSO.4.64.0708242252520.15344 at sea.ntplx.net>
            Daniel Eischen <deischen at freebsd.org> writes:
: On Fri, 24 Aug 2007, Warner Losh wrote:
: 
: > From: Daniel Eischen <deischen at FreeBSD.org>
: > 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.

There's much resistance to building everything that the build system
might be used being build static.  It adds too much time and
complexity to the build system, the opponents say.

: >> 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.

Should?  Yes.  However, it never has.  There has always been the
possibility that an incompatible change to libc would take out the
build tools.  People have been good enough to not change base ABIs to
prevent this from happening, for the most part.

: > 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.

But FBSD_0.9 could be used, no?

: 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.

I was thinking of leaving it in, undocumented, for the release.  We're
in a period of transition to the symbol versioning anyway.  If there's
one or two bumps as we do so, then so be it.  In the past, we've only
supported upgrading across major releases (eg, 5.x -> 6.0 but not
6.1).

And having a robust build system still doesn't solve the ports problem
I alluded to.  All of them would still need to be rebuilt.

I'm surprised that we're not looking at this as a dry-run for symbol
versioning to see how well it helps in a well controlled case and to
learn from something we can make a mistake on without huge
consequences.

Warner