Re: Removal of data on purge (Was: OpenMRS package is ready, I believe)
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:
misha@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 ...
misha@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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive: [🔎] 20101005080532.GA25692@an3as.eu">http://lists.debian.org/[🔎] 20101005080532.GA25692@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.
Reply to: