Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
X-Originating-IP: [202.7.175.111]
From: "Gareth Pearce" <tilps AT hotmail DOT com>
To: nwourms AT netscape DOT net
Cc: cygwin-apps AT sources DOT redhat DOT com
Subject: Re: [ITP]: Berkley DB v2
Date: Thu, 20 Jun 2002 11:42:58 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F18RAKCyyYCkNOYmPSy0002266c@hotmail.com>
X-OriginalArrivalTime: 20 Jun 2002 11:42:59.0096 (UTC) FILETIME=[A0514980:01C2184F]



>Hi,
>
>The reason is quite simple, it has to do with the format of the database.  
>When Sleepycat switches from v2->v3.0 it requires a database format 
>upgrade.  This makes it impossible to use v3.0 formatted databases with 
>applications dependant on v2 databases.  As such, those applications can 
>only link against v2 headers and libraries.  If you read my release 
>statement closely, you will note that my intention is to release the other 
>versions of  The Berkeley DB  in 3 day intervals.  So to answer your 
>question, yes  DB v4.0 will be released, but I want to release the other 
>versions first.  When v3 is released, it will co-exist with the v2 headers 
>and libraries, but establish itself as the primary DB by symlinking it's 
>libraries to /usr/lib/libdb.{a la dll.a}. Whichever db release you install 
>last will establish itself as the "default" db.  Optimally this should be 
>db4.0, so that is why it will be released last.

<note - i know little to nothing about db and havent looked at the packages>

Hmmm depending on release order seems rather dubious to me...
Would it not be better to have the symlink installed by postinstall script 
that checks if there is an existing symlink and only replacing it if the 
version of the one its pointing too is less then the one being installed?
same postinstall for all db packages - will work when a new db comes along 
(assuming that you are using some standard in versioned libs) - and doesnt 
rely on instalation order (which in my mind sounds sort of easy to break).
(hmmm would need a postuninstall script to chose highest remaining one to 
link it too as well)

my uninformed ~10^24 quarks.

Gareth.


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com