Oracle JDK 9 does not seems to contain jre directory, so oraclejre9
package now uses a dedicated archive file.
There is no 32-bit version nor arm version (yet). If Oracle releases
them, I will update the package.
As @oxij points out in [1], this breakage is especially serious because
it changes the contents of built environments without a corresonding
change in their hashes. Also, the revert is easier than I thought.
This reverts commit 3cb745d5a6.
[1]: https://github.com/NixOS/nixpkgs/pull/27427#issuecomment-317293040
This makes those files a bit easier to read. Also, for what it's worth,
it brings us one baby step closer to handling spaces in store paths.
Also, I optimized handling of many transitive deps with read. Probably,
not very beneficial, but nice to enforce the pkg-per-line structure.
Doing so let me find much dubious code and fix it.
Two misc notes:
- `propagated-user-env-packages` also needed to be adjusted as
sometimes it is copied to/from the propagated input files.
- `local fd` should ensure that file descriptors aren't clobbered
during recursion.
This reverts commit 9e56f3a9b5.
8u91 is Critical Patch Update (CPU), contains security vulnerability fixes.
8u92 is Patch Set Update (PSU), contains security vulnerability fixes
and other bug fixes.
Oracle says "Oracle strongly recommends that all Java SE users upgrade
to the latest CPU release available for a release family. Most users
should choose the CPU release."
http://www.oracle.com/technetwork/java/javase/downloads/cpu-psu-explained-2331472.html
So I made `oraclejdk8` package and `oraclejdk8psu` package for CPU and PSU.
Oracle changed the path of the files.
Previous versions looked like:
$ jar tf UnlimitedJCEPolicyJDK7.zip
UnlimitedJCEPolicy/
UnlimitedJCEPolicy/US_export_policy.jar
UnlimitedJCEPolicy/local_policy.jar
UnlimitedJCEPolicy/README.txt
The new version looks like:
$ jar tf jce_policy-8.zip
UnlimitedJCEPolicyJDK8/
UnlimitedJCEPolicyJDK8/local_policy.jar
UnlimitedJCEPolicyJDK8/README.txt
UnlimitedJCEPolicyJDK8/US_export_policy.jar
A better solution is probably just to trim the directory off completely.
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
Fixes#9044, close#9667. Thanks to @taku0 for suggesting this solution.
Now we have no modes starting with `/` or `+`.
Rewrite the `-perm` parameters of find:
- completely safe: rewrite `/0100` and `+100` to `-0100`,
- slightly semantics-changing: rewrite `+111` to `-0100`.
I cross-verified the `find` manual pages for Linux, Darwin, FreeBSD.
