delorie.com/archives/browse.cgi | search |
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 |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |