From owner-freebsd-arch Tue Feb 13 20:18: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id C1B3237B491 for ; Tue, 13 Feb 2001 20:18:04 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id PAA24140; Wed, 14 Feb 2001 15:17:55 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01K03SFHER1CO2JDJ3@cim.alcatel.com.au>; Wed, 14 Feb 2001 15:17:45 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f1E4HmU73629; Wed, 14 Feb 2001 15:17:48 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Wed, 14 Feb 2001 15:17:48 +1100 From: Peter Jeremy Subject: Re: Proposal on shared libs version values. In-reply-to: <20010213130926.A79651@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Tue, Feb 13, 2001 at 01:09:26PM -0800 To: freebsd-arch@FreeBSD.ORG Cc: Peter Wemm Mail-followup-to: freebsd-arch@FreeBSD.ORG, Peter Wemm Message-id: <20010214151748.Q90937@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200102131717.f1DHHNW39519@harmony.village.org> <200102131941.f1DJffU66659@mobile.wemm.org> <20010213130926.A79651@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Firstly, I also like the idea of a `development' shared library version that can change as necessary before -CURRENT forks at each major release. On 2001-Feb-13 13:09:26 -0800, David O'Brien wrote: >On Tue, Feb 13, 2001 at 11:41:41AM -0800, Peter Wemm wrote: >> When libc is built, we could link it with "-h libc.so.5-13-Feb-2001" > >Actually I think I like libc.so.5. to stand for a development >version of libc.so.5 better than the libc.so.500 scheme. It's not clear to me whether you are proposing that be the date of the buildworld, or the date of the last library API change. In the former case, you wind up bloating /usr/lib much faster[1] and the values don't mean anything to anyone else (since it depends what timezone you are in and when you ran buildworld). Neither case handles the situation where multiple API changes occur in a day - which might be rare but isn't entirely impossible. Given access to CVS, you can easily translate a version number to the date on which the change occurred in any case. [1] The only way I know of to verify that it's safe to delete an old shared library is to run ldd on all dynamic executables. (Maybe within a date range). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message