#51682: jython: update to 2.7.0 -------------------------------+-------------------------------- Reporter: aaron+macports@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: jython | -------------------------------+-------------------------------- Comment (by aaron+macports@…): Thanks very much for your review.
Why not unify the destroot and post-destroot block?
The `installer` variant overrides the destroot block, but should use the same post-destroot block. If there is a more appropriate way of doing this, please let me know.
Making a directory in ${prefix}/share/java world-writable doesn't seem like a very good idea to me. Is this really necessary? Can we generate the contents of this file with privileges in post-activate instead to avoid making the file world-writeable?
Jython caches information about JARs it encounters, for speed and to support Java static imports. By default this is done in `cachedir/packages` in the installation dir, which is expected to be writable by the user running jython. There's a bit about it in the jython FAQ, which suggests giving it `a+rw`: http://www.jython.org/archive/22/userfaq.html#why-do-i-get-the-error-can-t -create-package-cache-dir-cachedir-packages I agree that it's not ideal to have this be world-writable. Unfortunately the main configuration for this (in the `registry` file) doesn't support expanding envars, so we can't simply put the cachedir in the user's home. Not adjusting the permissions at all would result in an error and a subtly broken install. Do you have a suggestion for what to do here? Ideas: 1. Wrap the jython launcher with a script that puts the cachedir in the user's home 2. Install without making the cachedir writeable and merely print instructions telling the user to e.g. alias `jython` to `jython -Dpython.cachedir=$HOME/.jython_cachedir` or something 3. Create a `jython` user group and restrict writing to the cachedir to members of the group I have addressed your other points. -- Ticket URL: <https://trac.macports.org/ticket/51682#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X