From owner-cvs-user  Mon Mar 13 23:00:22 1995
Return-Path: cvs-user-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA02433 for cvs-user-outgoing; Mon, 13 Mar 1995 23:00:22 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA02414; Mon, 13 Mar 1995 23:00:00 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA11402; Tue, 14 Mar 1995 16:55:56 +1000
Date: Tue, 14 Mar 1995 16:55:56 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199503140655.QAA11402@godzilla.zeta.org.au>
To: bde@zeta.org.au, phk@ref.tfs.com
Subject: Re: cvs commit: src/release/compat20 libgcc.so.261.0.uu
Cc: CVS-commiters@freefall.cdrom.com, cvs-user@freefall.cdrom.com,
        phk@freefall.cdrom.com, pst@shockwave.com, rgrimes@gndrsh.aac.dev.com
Sender: cvs-user-owner@freebsd.org
Precedence: bulk

>> This only works because libgcc*.c hasn't changed since before FreeBSD-2.0R.
>> If it had changed earlier then we would have already fought this battle.
>checking out to the tag will work.

For those with cvs'ed sources.

>> I'm worried about the same problem for our own libraries.  I don't like
>> having to keep old library binaries that I can't rebuild.  If we were
>> less sloppy about incrementing the library version numbers then we
>> might have already fought battles over this.  There might be dozens of
>> versions and shared libraries occupying more space than they save in
>> executables.
> You want to dump shared libs all together ?  or are you talking about
> people doing upgrades and not zapping the old shlibs ?

I'm talking about version control problems.  How are you going to maintain
the 2.0 libraries for the 2.1 release?  What if there were different
library version numbers for every SNAP?

Bruce