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/[email protected]/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 [email protected] > with a subject of "unsubscribe". Trouble? Contact > [email protected] > Archive: http://lists.debian.org/[email protected] > > > 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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
