Thank you all for your comments about purge. So here's the OpenMRS story - perhaps you have some opinions, but I see this as paralleling gnumed, specifically: * when we _install_ the package, _no_ databases are created * when we _purge_ the package, _no_ databases are erased
The databases themselves are created by the user in the initial setup wizard that they run by going to http://localhost:8080/openmrs Thus, it seems based on your comments below re gnumed and README.Debian, that since the user is creating the database, they should remove them as well. Or am I misinterpreting? Thank you Misha p.s. From a programming viewpoint, we could certainly removed the databases. However, from a practical viewpoint, I am guessing that not all OpenMRS implementers are 100% experts in computers and Linux. I could easily see someone getting confused, purging a package, and then being whoops all my medical records are gone! forever... After all, the inherent checks in a database system favor _not_ losing data normally (my understanding is that, in OpenMRS, we do not delete fields from the database generally, instead we have a "void" flag that marks when a field is no longer applicable/relevant). p.p.s. I just checked and even purging mysql does not actually remove database data: mi...@squeeze:~/openmrs/trunk$ sudo aptitude purge `dpkg -l | grep mysql | awk '{print $2}'` -y The following packages will be REMOVED: libdbd-mysql-perl{p} libdbi-perl{u} libmysqlclient16{p} libnet-daemon-perl{u} libplrpc-perl{u} mysql-client-5.1{p} mysql-common{p} mysql-server{p} mysql-server-5.1{p} mysql-server-core-5.1{p} 0 packages upgraded, 0 newly installed, 10 to remove and 2 not upgraded. Need to get 0B of archives. After unpacking 54.8MB will be freed. (Reading database ... 38841 files and directories currently installed.) Removing mysql-server ... Removing mysql-server-5.1 ... Stopping MySQL database server: mysqld. Purging configuration files for mysql-server-5.1 ... Removing mysql-client-5.1 ... Removing libdbd-mysql-perl ... Processing triggers for man-db ... (Reading database ... 38657 files and directories currently installed.) Removing libdbi-perl ... Processing triggers for man-db ... (Reading database ... 38508 files and directories currently installed.) Removing libmysqlclient16 ... Purging configuration files for libmysqlclient16 ... (Reading database ... 38499 files and directories currently installed.) Removing libplrpc-perl ... Removing libnet-daemon-perl ... Processing triggers for man-db ... (Reading database ... 38468 files and directories currently installed.) Removing mysql-common ... Purging configuration files for mysql-common ... dpkg: warning: while removing mysql-common, directory '/etc/mysql' not empty so not removed. Removing mysql-server-core-5.1 ... Processing triggers for man-db ... mi...@squeeze:~/openmrs/trunk$ sudo ls /var/lib/mysql/ debian-5.1.flag ibdata1 ib_logfile0 ib_logfile1 mysql mysql_upgrade_info openmrs Andreas Tille-5 wrote: > > On Tue, Oct 05, 2010 at 09:28:47AM +0200, Karsten Hilbert wrote: >> I think it is considered good practice to not remove >> database data files due to them being considered user >> content despite that being stored in a system directory. > > Probably it is good practice to *remove* a package if you want some > content saved. If you say *purge* you should get a *purge* of anything > created by the program (because you asked for it). > > Remark: I do not even try to accomplish this for GNUmed server package. > The rationale behind this is that the local admin *manually* creates the > database (according to the advise in README.Debian). Anything an admin > has done *manually* should not be undone by package removal and moreover > I do not really have a save chance to do so because this would include > wild guessing which name the admin has given the database (which can be > different from the default name). > > There is probably no clear borderline between data a package > automatically creates and admin-/user-created databases and so there is > some space for a decision of the maintainer to remove data or not. It > might be that as a user would prefer the safer way to keep the data but > you can not expect this. If you ask the package manager to purge you > should definitely expect a purge of the database. > > Kind regards > > Andreas. > > -- > http://fam-tille.de > > > -- > To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/20101005080532.ga25...@an3as.eu > > > -- View this message in context: http://old.nabble.com/OpenMRS-package-is-ready%2C-I-believe-tp29833953p29889391.html Sent from the debian-med mailing list archive at Nabble.com. -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/29889391.p...@talk.nabble.com