This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: [ITP]: Berkley DB v2
- 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
- Date: Thu, 20 Jun 2002 19:30:57 +0000
- Subject: Re: [ITP]: Berkley DB v2
- Bcc:
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