jython: Fix issue upgrading from 2.5.2 to 2.7.0

[amake (Aaron Madlon-Kay)]

As reported on ​macports-users, when upgrading from jython 2.5.2 to 2.7.0 there is a conflict with an existing file in jython's package cache that prevents activation.

Analysis by Clemens Lang on the list (for some reason not visible on the web version linked above) is correct:

From the error message if seems that the old jython port didn't install files in /opt/local/share/java/jython/cachedir/packages, but the new version comes with a pre-populated cachedir and now causes these problems if the cache has been generated by other means meanwhile.

I don't know anything about jython, but if somebody more familiar with jython can confirm that this sounds about right, I think I know a way to work around this: Add a pre-activate {} block that deletes these files (since jython should be the only port putting files in this directory if I understand things correctly).

Yeah I know what it says, but I’m afraid to force the activation because I don’t know what else will be affected.

Since these are just cache entries, it should be safe to force activation.

The attached patch addresses the issue.

[ryandesign (Ryan Carsten Schmidt)]

Should the cache be deleted whenever the port is upgraded? This patch will do that. If this is a cache that will change itself as users use the port, the user may not want it cleared.

[amake (Aaron Madlon-Kay)]

Starting in 2.7.0 we are installing by default a wrapper script that places the cache in the user's home directory, because otherwise the cache needs to be world-writable and this is undesirable from a security standpoint.

Wiping the system cache is OK in my opinion because in the default setup no one will be using it, and it's not actually very intensive to create in the first place (it is generated on the fly when jython loads a novel JAR, and in my experience it's plenty fast, like ~1s for the first run which includes all JARs bundled with the system Java).

[neverpanic (Clemens Lang)]

Thanks, committed in r151154 with a revision bump, because we need to force a rebuild (or rather re-package, but we don't separate those) for the metadata of the generated package to change so that this takes effect on users' machines.