Date: Wed, 14 Feb 2001 15:17:48 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: freebsd-arch@FreeBSD.ORG Cc: Peter Wemm <peter@netplex.com.au> Subject: Re: Proposal on shared libs version values. Message-ID: <20010214151748.Q90937@gsmx07.alcatel.com.au> In-Reply-To: <20010213130926.A79651@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Tue, Feb 13, 2001 at 01:09:26PM -0800 References: <200102131717.f1DHHNW39519@harmony.village.org> <200102131941.f1DJffU66659@mobile.wemm.org> <20010213130926.A79651@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <TrimYourCc@NUXI.com> 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.<date> 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 <date> 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 <date> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010214151748.Q90937>