Donovan Baarda wrote:

But this is redundant... if the package is installed, the corresponding *.py
files _should_ be unpacked. How is testing for the existance of a file any
better indication than testing for installation of the package?

True... I think I'll try to blame my flawed argument on lack of caffeine in the bloodstream.


[...]

This is an interesting issue I hadn't considered. However, I can't see how
seperate compilation scripts do a better job of avoiding this problem than
dpkg-reconfigure.

Since, in the absence of debconf, all dpkg-reconfigure does is run

   /var/lib/dpkg/info/package.postinst configure <current-version>

/I guess editing the postinst would be fine as well. /However, it still seem to me that having recompilation separate from installing documentation, menus, MIME types and whatever else might be worthwhile.

It might also be nice to have separate files that list the directories or source files to compile for each package, and have python-central call compileall itself, but I guess this is a separate issue.

[...]

So the postinst scripts get passed the version upgraded from? (I should know
this :-)

I should have checked too. See section 6 of Policy for details, especially what can happen if an error occurs, but the postinst is the one script that _doesn't_ get called with the other version number. The old version's prerm and postrm, and the new version's preinst, could all check whether an incompatible upgrade was going to or had occurred. In this case, I guess they'd set a flag and delete the old *.py[co] files.







Reply via email to