On Tue, Mar 01, 2005 at 04:34:44PM +0100, Lars Roland wrote:
> 2) When you update the database software from, say, version 1.0 to 1.1
> then it would be preferable to NOT generate all the tables again (that
> is, mysoftware-db 1.1 should just alter or extend the tables that
> mysoftware-db 1.0 created). Can I somehow create a package that
> depends on earlier versions of itself ? - or is there some other
> scheme that is used when you are in a situation where software depends
> on earlier versions of itself ?.
I have that problem with JFFNMS. There are two seaprate issues.
On a new install, create the database
On an upgrade, upgrade database schema.
First thing is to ask the admin, they might not like you playing with
the database!
I do all this magic in the postinst script.
A new install will be called as
postinst configure
An upgrade will be called as
postinst configure (last version)
So you do a test like [ -z "$2" ] to see if it is a new install.
If so I have a mysql or postgresql dump and I just pipe that into the
database client.
Now the upgrades are trickier. There are a set of files for each
version, called jffnms-(oldver)-(newver).mysql. It doesn't have to be
multiple files for each version, but there definitely should be a file
per version change, unless there is no DB changes.
I then start at the oldest version (0.7.2) and use dpkg
--compare-versions "$2" lt "0.7.3-1"
EG, was the last configured version ("$2") less than 0.7.3-1, which
means it was 0.7.2-something
I then call a function upgrading the database from 0.7.2->0.7.3
I keep doing that for each step there are database changes, so there
are 8 of these in postinst.
- Craig
--
Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer
csmall at : enc.com.au ieee.org debian.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
