This is unfortunately rather normal. Many packages fail to uninstall because removing all of the acs_object and cr_item records is fairly difficult.
This being the case, what does this tell us? I've been trying to work out why even some of the most mature current-generation packages like Bug-Tracker don't uninstall cleanly as a means to figuring out how they work. Wonkiness seems to erupt when the deletion routines descend into the acs object system and the CR. Are the uninstall procs incorrect? Are there actually undiscovered problems with the way acs_objects and CR entities get created that the (correct) uninstall procs uncover? Are the core mechanisms OK and the problem is entirely in the package-specific drop scripts?
Presumably the answer may vary from package to package. For instance, Bug-Tracker stalls in the middle of its drop script (../bug-tracker-drop.sql). There were some obvious simple errors (a couple drop function calls with incorrect parameter lists). Even when those are fixed and the drop script runs fine via psql, it still barfs when being run within OpenACS. No clue why at this point. (This is a HEAD install btw.)
However, it seems vital to me that packages uninstall cleanly. A botched uninstall leaves the entire database's integrity in question. In a development setting, simply dropping the db and starting over is acceptable, if tedious. But that's not an option in a production site, obviously.
As packages get designed with more and more inter-package dependencies, it becomes essential that reliable uninstall procedures be present so that during development and testing, we don't have to completely start over with a new install each time. If my new package doesn't remove cleanly, I'm not confident I've built it cleanly. And I want to be certain that any uninstall problems are due to my drop scripts, not the complex series of calls that begin with apm_package_delete (in packages/acs-tcl/tcl/apm-install-procs.tcl)
