FR: Remove or not the database on uninstall based on the user choice

Bug #582933 reported by dmezentsev
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openbravo-erp (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: openbravo-erp

---------- Forwarded message ----------
From: Dmitry Mezentsev
Date: 17 May 2010 20:22
Subject: Re: Uninstall of Openbravo ERP through Ubuntu Software Center does not remove the database (or License Info)
To: John Fandl

Hello John,

Thanks for these inputs.
>It seems to me that “remove” should remove everything (especially the activation file—since not doing so could cause us to >incorrectly accuse someone of overusing a single system key, when by doing the “remove” they would naturally figure the key
>was no longer in use).

>I am not sure as to the design of the package in this scenario (removal via the Software Center), but it seems wrong to me, >which is why I mention it.

The package was designed the way it is working now: to maintain user-data on executing standard "remove" command and cleaning everything on "remove" with a "-- purge" option. This is documented in the wiki.

There are 2 reasons behind:
* User data (especially the one we are talking about) is very critical and we decided that if to delete it then only based on the explicit user request. If you leave the data then you can always delete but if it is removed then there is nothing else you can do (if you want).
* This is standard practice for the packages - to leave user data, configuration files (if they modified) on an standard remove command so Linux users might expect it.

Anyway to make algorithm we have chosen more visible and put the decision on the end-user we can for example during un-installation process ask for the preferences - keep user data like DB or remove it. If you are OK we´ll register feature request.

summary: - Remove or not the database on uninstall based on the user choice
+ FR: Remove or not the database on uninstall based on the user choice
Revision history for this message
Juan Pablo Aroztegi (jpabloae) wrote :

Dmitry,

We are following the Debian/Ubuntu standards here, the ones you have already mentioned. We gave the user the option to choose what to do in the first version of the package, but the Ubuntu developers reviewing the package recommended/asked us to use the standard method instead. I find it reasonable to follow the Debian/Ubuntu rules as much as possible.

Changed in openbravo-erp (Ubuntu):
assignee: nobody → Juan Pablo Aroztegi (jpabloae)
Revision history for this message
dmezentsev (dmitry-mezentsev) wrote :

Juan Pablo,

I understand your point and share it from one side.

From another side with all these moves of putting the package into the Software Center we want to attract not "techy" users by being able to easily install / uninstall and evaluate the package.

To preserve both.
Is it possible not to change the package command line behavior so that for those who use command line (whom we preserve "techy") nothing changes (exists remove and remove --purge option) but while doing the same from the software center the question is asked?

Revision history for this message
Juan Pablo Aroztegi (jpabloae) wrote :

As far as I know the graphical package manager tools are just front-ends to the command line interface. It's usually the other way around: the graphical interfaces tend to ask less questions than their command line equivalents. In this case they are the same.

This is a debian packaging standard we have to follow.

Revision history for this message
dmezentsev (dmitry-mezentsev) wrote :

OK, thanks.

That´s a pity we cannot understand that package removal is called from the Software Center. It would be really great to distinguish them...

But if there is no way to do it then lets keep it as it is and I´ll inform John Fandl (he was asking for it).

Changed in openbravo-erp (Ubuntu):
assignee: Juan Pablo Aroztegi (jpabloae) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.