Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Aug 2007 23:08:01 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        src-committers@freebsd.org, peterjeremy@optushome.com.au, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, yar@comp.chem.msu.su
Subject:   Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h
Message-ID:  <Pine.GSO.4.64.0708242252520.15344@sea.ntplx.net>
In-Reply-To: <20070824.172212.74696955.imp@bsdimp.com>
References:  <20070824215515.GF16131@turion.vk2pj.dyndns.org> <20070824220244.GH87451@elvis.mu.org> <Pine.GSO.4.64.0708241819220.13181@sea.ntplx.net> <20070824.172212.74696955.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 Aug 2007, Warner Losh wrote:

> From: Daniel Eischen <deischen@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.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0708242252520.15344>