Re: Removal of data on purge (Was: OpenMRS package is ready, I believe)
Hi Andreas et al:
I've sent this to Andreas privately but will forward to list as it might be
relevant to others. I appreciate your advice re policy. I have actually
already implemented your policy-compliant solution (in current subversion).
In any case, I think either way the end user will most likely be happy (and
most likely I am guessing people will _not_ want to purge the database on
removal - I, for one, would be the rare exception to that rule, but...).
There are two somewhat more important questions:
1. I have alerted Andreas to this and this might be a potentially
technically minor thing, but it would be nice to solve sooner rather than
later if possible.
I will post details at the bottom but basically it involves an inconsistency
between the patch I included in 1.6.1-1 and the patch that actually got
committed to 1.6.2. When 1.6.2 gets released upstream, and a 1.6.2 version
gets into the deb, users who upgrade will need to have the appropriate
config file modified. This can certainly be done, but we can also circumvent
the entire ordeal if we can push 1.6.1-2 up before 1.6.1-1 even gets
release. However, I don't want to rock the boat - I understand careful
review is important and this issue is relatively minor.
Just in case, I will upload the 1.6.1-2 version to debian mentors (this also
changes the description to be lintian compliant, i.e., no first author
names). Again, I believe this is a relatively minor issue and so there is no
need to do anything if standard procedure is to wait for a full review of
1.6.1-1.
2. How do we get Ubuntu packages in the debian-med PPA? What is the process
I mean?
Thank you
Misha
Andreas Tille-5 wrote:
>
> On Wed, Oct 06, 2010 at 01:41:23PM -0500, Misha Koshelev wrote:
>> Sorry I've read all your emails but I'm a little slow on the uptake.
>
> No problem - nobody will ask you for speeding up.
>
>> ...
>> http://da2i.univ-lille1.fr/cgi-bin/man/man2html?debconf-devel+7
>> http://manpages.ubuntu.com/manpages/hardy/man7/debconf-devel.7.html
>> "Note that if your package???s sole use of debconf is in the postrm,
>> you
>> should make your package???s postinst
>> source
>> /usr/share/debconf/confmodule, to give debconf a chance to load up your
>> templates file into its database. Then the templates will be available
>> when your package is being purged."
>> This implies it's okay to have sole use of debconf be in postrm.
>>
>> http://www.mail-archive.com/debian-mentors@lists.debian.org/msg37547.html
>> "If you use debconf, you should really ask that question when the package
>> is removed, not when its conffiles are purged, though you may only want
>> to delete the database files on purge. The rationale for this is that
>> there is no mechanism in place to guarantee that a certain other
>> package, in this instance debconf, is installed at purge time (though
>> the assumption may be fairly safe). The least bad solution I can see is
>> to ask at remove time, store the result outside of debconf
>> (/etc/default) and kill the db on purge if requested."
>> This also implies its okay to ask at remove time, whether on remove or
>> purge.
>
> In principle I would agree that finally it makes more sense to ask the
> question if you are about to remove something and not an undetermined
> time in advance (install time).
>
>> But the Debian Policy Manual seems definitive it is _not_ okay so I'll
>> go with that:
>> http://www.debian.org/doc/debian-policy/ch-binary.html#s-maintscriptprompt
>> "Any necessary prompting should almost always be confined to the
>> config or postinst script."
>> (and postrm is not mentioned)
>
> In my mail recommended the policy conform solution. However, I think
> policy should not be a law if it makes sense to follow other
> precedences. So if you prefer to ask in *rm script rather than at
> config time I would not veto this. There is no point in blindly
> following some rules if an exception makes sense.
>
> Kind regards and thanks for your intensive research
>
> 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: [🔎] 20101006194650.GA4075@an3as.eu">http://lists.debian.org/[🔎] 20101006194650.GA4075@an3as.eu
>
>
>
Details: the problem is something that might be a problem
when/if users upgrade from 1.6.1 to 1.6.2.
The field name that I created for 1.6.1-1 in the openmrs.xml is
runtime.properties.directory.
However, the final patch that went into 1.6.2 uses
application.data.directory
http://tickets.openmrs.org/browse/TRUNK-1779
http://source.openmrs.org/changelog/OpenMRS/?cs=15768
Potential problem: when/if users upgrade to 1.6.2, OpenMRS will look
for application.data.directory, not find it, and try
/usr/share/tomcat6/.OpenMRS (user's home), which does not exist.
Potential fixes:
1. 1.6.1-2 is ready and could be release. But this might be difficult
with current Debian system as you explained.
2. We come up with some kind of fix on upgrade. This would not be
difficult but I'm not sure where the appropriate place for this would
be or if it's allowed (I could come up with one if you think its best
solution).
Anyway, just wanted to give you a heads up. Its not a major problem
but something that certainly will have to handled when/if 1.6.2 is
released and users need to upgrade.
Thank you
Misha
--
View this message in context: http://old.nabble.com/OpenMRS-package-is-ready%2C-I-believe-tp29833953p29901999.html
Sent from the debian-med mailing list archive at Nabble.com.
Reply to: