Opened 8 years ago
Closed 8 years ago
#51682 closed update (fixed)
jython: update to 2.7.0
Reported by: | amake (Aaron Madlon-Kay) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | haspatch | Cc: | robsonpeixoto@…, neverpanic (Clemens Lang) |
Port: | jython |
Description
Attachments (1)
Change History (9)
comment:1 Changed 8 years ago by amake (Aaron Madlon-Kay)
comment:2 Changed 8 years ago by mf2k (Frank Schima)
Cc: | robsonpeixoto@… added |
---|
Cc reporter of duplicate #39622.
comment:3 Changed 8 years ago by neverpanic (Clemens Lang)
A couple of comments:
- Why not unify the destroot and post-destroot block?
- 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?
- The livecheck doesn't work
- The quotes around the value for
master_sites
aren't necessary; Tcl does not behave like many other languages w.r.t. to quoting
Other than that, this looks commit-ready. It builds and seems to work fine.
comment:4 Changed 8 years ago by neverpanic (Clemens Lang)
Cc: | cal@… added |
---|
comment:5 Changed 8 years ago by amake (Aaron Madlon-Kay)
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:
- Wrap the jython launcher with a script that puts the cachedir in the user's home
- Install without making the cachedir writeable and merely print instructions telling the user to e.g. alias
jython
tojython -Dpython.cachedir=$HOME/.jython_cachedir
or something - Create a
jython
user group and restrict writing to the cachedir to members of the group
I have addressed your other points.
Changed 8 years ago by amake (Aaron Madlon-Kay)
Attachment: | Portfile.diff added |
---|
comment:6 Changed 8 years ago by amake (Aaron Madlon-Kay)
I have implemented idea 1 above. We now install a wrapper script that provides -Dpython.cachedir=$HOME/.jython_cachedir
as a default argument.
comment:8 Changed 8 years ago by neverpanic (Clemens Lang)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Committed in r150984. Thank you for the patch and the hard work.
Note that this ticket obsoletes both #39622 and #47036.