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: [203.26.31.8]
From: "Gareth Pearce" <tilps AT hotmail DOT com>
To: cwilson AT ece DOT gatech DOT edu
Cc: cygwin-apps AT sources DOT redhat DOT com
Subject: Re: [ITP]: Berkley DB v2
Date: Thu, 20 Jun 2002 19:30:57 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F207f69aZbLAX3cf3ed00000195@hotmail.com>
X-OriginalArrivalTime: 20 Jun 2002 19:30:57.0785 (UTC) FILETIME=[00853690:01C21891]



>Gareth Pearce wrote:
>
>><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?
>
>
>What if I *want* to revert to an older version?
in that case - 'no matter what' (as far as I can see) - your either going to 
have to remove the packages associated with the newer versions - or take the 
whole thing into your own hands and refix the links every time a new 
revision of a db packages comes out... (please note i could be talking junk 
for all i know here) (okay so it would be as easy as rerunning a script - 
but still :P - for all i know you could make it so the script by default as 
setup runs it does what i suggest - and when passed a force parameter or 
something it ignores version checking)
In the current system - if you want to patch db2 - release a new db2 - your 
going to have to release db3 and db4 as Well - in order to have everyones 
symlinks working nicely? (this is probably the nit that bothers me most)

>
>
>>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).
>
>
>Probably.  But the postinstall scripts are all there.  So, you can manually 
>re-execute:
>
>/etc/postinstall/libdb3.3-devel.sh.done
>
>and assert the "current" links to the 3.3 version, or 4.0, or whatever.

really depends how often you want to have to tell people to do this I am 
thinking... - whats the law - make the commonest case the easiest? (hmmm 
thinking hoffman coding in the perl 6 reg exp thiny i read for no reason)

>
>>(hmmm would need a postuninstall script to chose highest remaining one to 
>>link it too as well)
>
>
>Probably so, but the logic gets tricky.  I think this one can be tabled 
>until it becomes an issue.  Under the current scheme, there are two fixes 
>if you uninstall (the latest) db-devel:
>   1) reinstall (the latest minus one) db-devel
>   2) execute /etc/postinstall/libdb(thelatestminusone)-devel.sh.done 
>manually.
>
>This will probably be so rare a problem, that I believe these two options 
>are sufficient.

same 2 options would be under my system - or postinstall script... *shrug*
>
>--Chuck

well its not me who has to handle the requests 'why is my db install 
broken?'
so I dont realy mind :P (not you either :P)

I dont think it will be quite as rare - but i certainly dont have close to 
the same level of experience as a maintainer as you.


Gareth

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com