A dependency on unzip will never be registered since unzip is available
on all supported platforms (since FreeBSD 8.0).
Note that it's pulled in by a non-default option.
In this particular case, USES=zip:infozip is set, so unzip is pulled in
anyway through this mechanism (so explicit callout is still redundant)
Approved by: infrastructure blanket (removal of redundant deps)
created by pkg(8) during upgrades
It happens because the deinstall script tries to clean up the potential manual
VM registration by cleaning out all symlinks to bin/javavm
Given all VM are registring/unregistering themselves this part is not needed
The other thing the script was doing handling the configuration which has been
replaced by @sample.
pkg-install has been modified to drop the handling of the configuration file but
keep the auto registration if all VM found. While this part is not necessary as
well, we keep it because otherwise anyone doing delete/install on javavmwapper
version 2.5 being the installed version would end up with all VM unregistered.
The pkg-install should be removed after EOL of FreeBSD 10.3
PR: 210313
MFH: 2016Q3
The FreeBSD Ports Collection already has 1.45 version of the Bouncy Castle and
this new port is based on java/bouncycastle.
Newer versions are not API-compatible with that older one. Some say they should
be given 2.x version numbers. So, this new version comes as distinct port
java/bouncycastle15 instead of update for existing java/bouncycastle15 to keep
old API version available.
This is neccessary dependency for other port updates, e.g. newer version of
iText PDF (devel/itext) requires new API of modern Bouncy Castle versions.
PR: 211316
Submitted by: Eugen Grosbein <eugen=at=grosbein.net>
everything at once. Sometime, rename post-install into a options helper
target.
I did not fix ports that were such a mess that I could not figure out
what they really wanted to do. I also did not change ports that had
some version of an auto-plist code in post-install, for the same reason.
With hat: portmgr
Sponsored by: Absolight
aparapi is an open source API for expressing data parallel workflows in Java.
Originally an AMD product, Aparapi was released to open source on September
14, 2011. Aparapi is an API for expressing data parallel workloads in Java
and a runtime component capable of converting the Java# bytecode of compatible
workloads into OpenCL# so that it can be executed on a variety of GPU devices.
WWW: https://github.com/aparapi/aparapi
PR: 204024
Submitted by: dieterich@ogolem.org
uses pty4j-0.6.jar which seems to include FreeBSD support.
Do not install pty4j-0.5.jar, install only the native component of pty4j.
PR: 209552
Submitted by: bsam (me)
Approved by: Tobias Kortkamp <t@tobik.me> (maintainer)
