Opened 3 years ago
Last modified 2 years ago
#64924 assigned enhancement
openjdk## ports should be meta ports
Reported by: | zman0900 (Dan Ziemba) | Owned by: | usersxx |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | mascguy (Christopher Nielsen), breun (Nils Breunese), amake (Aaron Madlon-Kay), usersxx, cooljeanius (Eric Gallager) | |
Port: | openjdk17 openjdk11 openjdk8 |
Description
The openjdk ports were previously meta packages, but now are not and also depend on "openjdk##-bootstrap". As a meta ports, this seemed to allow other ports to just depend on "openjdk11" or "openjdk17", while the user could choose which actual implementation to install, such as "openjdk17-temurin".
Now if I want to use "openjdk17-temurin" and also have, for example, "dbeaver-community" installed (dependency on "openjdk17"), my system ends up with 3 separate JDKs installed - "/Library/Java/JavaVirtualMachines/" contains "openjdk17", "openjdk17-bootstrap", and "openjdk17-temurin".
Change History (11)
comment:1 Changed 3 years ago by usersxx
comment:2 follow-up: 3 Changed 3 years ago by breun (Nils Breunese)
As a meta ports, this seemed to allow other ports to just depend on "openjdk11" or "openjdk17", while the user could choose which actual implementation to install, such as "openjdk17-temurin".
I don't think the user could actually choose which implementation to use, although that would be nice. Before openjdk11
and openjdk17
would just install a particular OpenJDK distribution (Eclipse Temurin on x86_64, Azul Zulu on arm64).
comment:3 follow-up: 4 Changed 3 years ago by usersxx
Replying to breun:
As a meta ports, this seemed to allow other ports to just depend on "openjdk11" or "openjdk17", while the user could choose which actual implementation to install, such as "openjdk17-temurin".
I don't think the user could actually choose which implementation to use, although that would be nice. Before
openjdk11
andopenjdk17
would just install a particular OpenJDK distribution (Eclipse Temurin on x86_64, Azul Zulu on arm64).
You can just install azul zulu by using sudo port install openjdk11-zulu
and sudo port install openjdk17-zulu
. You can install eclipse temurin by using sudo port install openjdk11-temurin
and sudo port install openjdk17-temurin
.
comment:4 follow-up: 6 Changed 3 years ago by breun (Nils Breunese)
Replying to usersxx:
Replying to breun:
As a meta ports, this seemed to allow other ports to just depend on "openjdk11" or "openjdk17", while the user could choose which actual implementation to install, such as "openjdk17-temurin".
I don't think the user could actually choose which implementation to use, although that would be nice. Before
openjdk11
andopenjdk17
would just install a particular OpenJDK distribution (Eclipse Temurin on x86_64, Azul Zulu on arm64).You can just install azul zulu by using
sudo port install openjdk11-zulu
andsudo port install openjdk17-zulu
. You can install eclipse temurin by usingsudo port install openjdk11-temurin
andsudo port install openjdk17-temurin
.
Yes, you can do those things, but a port cannot specify that it depends on 'some JDK 11' or 'some JDK 17'. A port can only depend on a specific JDK implementation, or it can use the java.version
and java.fallback
properties from the java PortGroup, but those always use the openjdk{major}
ports. It would be nice if ports could indicate that they depend on a port which provides the 'Java 17' capability, without a hardcoded dependency on a specific port, so that if you already have for instance Eclipse Temurin 17 or Azul Zulu 17 or SapMachine 17 installed, the dependency is satisfied and not another JDK needs to be installed.
comment:5 Changed 3 years ago by zman0900 (Dan Ziemba)
Yeah, I think I have confused how this used to work with another system's package manager, such as the "provides" capability of Arch's pacman.
comment:6 Changed 3 years ago by usersxx
As a meta ports, this seemed to allow other ports to just depend on "openjdk11" or "openjdk17", while the user could choose which actual implementation to install, such as "openjdk17-temurin".
I don't think the user could actually choose which implementation to use, although that would be nice. Before
openjdk11
andopenjdk17
would just install a particular OpenJDK distribution (Eclipse Temurin on x86_64, Azul Zulu on arm64).You can just install azul zulu by using
sudo port install openjdk11-zulu
andsudo port install openjdk17-zulu
. You can install eclipse temurin by usingsudo port install openjdk11-temurin
andsudo port install openjdk17-temurin
.Yes, you can do those things, but a port cannot specify that it depends on 'some JDK 11' or 'some JDK 17'. A port can only depend on a specific JDK implementation, or it can use the
java.version
andjava.fallback
properties from the java PortGroup, but those always use theopenjdk{major}
ports. It would be nice if ports could indicate that they depend on a port which provides the 'Java 17' capability, without a hardcoded dependency on a specific port, so that if you already have for instance Eclipse Temurin 17 or Azul Zulu 17 or SapMachine 17 installed, the dependency is satisfied and not another JDK needs to be installed.
Actually, java.version
checks if a specific JDK version is installed or not. If a Installed JDK fulfils java.version
, MacPorts will use it. If there is no JDK that fulfils java.version
, java.fallback
will be installed
comment:7 Changed 3 years ago by usersxx
Cc: | usersxx added |
---|
comment:8 Changed 3 years ago by catap (Kirill A. Korinsky)
Right now -zulu
ports are required for M1 machine.
For example I have a clean macOS 12 M1 machine where I'm installing maven3
and it fails:
catap@Kirills-mini-m1 ~ % sudo port install maven3 ---> Computing dependencies for maven3 The following dependencies will be installed: autoconf bash gettext gettext-runtime gettext-tools-libs gmake libiconv libtextstyle m4 maven_select ncurses openjdk11 openjdk11-zulu Continue? [Y/n]: y ... ---> Verifying checksums for openjdk11 ---> Extracting openjdk11 ---> Configuring openjdk11 Error: Failed to configure openjdk11: consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk11/openjdk11/work/jdk-11.0.15+10/config.log Error: Failed to configure openjdk11: configure failure: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk11/openjdk11/main.log for details. Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug. Error: Processing of port maven3 failed ---> Some of the ports you installed have notes: openjdk11-zulu has the following notes: If you have more than one JDK installed you can make openjdk11-zulu the default by adding the following line to your shell profile: export JAVA_HOME=/Library/Java/JavaVirtualMachines/openjdk11-zulu/Contents/Home catap@Kirills-mini-m1 ~ %
the same happened with sbt
:
catap@Kirills-mini-m1 ~ % sudo port install sbt ---> Computing dependencies for sbt The following dependencies will be installed: autoconf bash brotli bzip2 cctools freetype gettext gettext-runtime gettext-tools-libs gmake libiconv libpng libtextstyle m4 ncurses openjdk8 openjdk8-bootstrap pkgconfig xz zlib Continue? [Y/n]: y ... ---> Extracting openjdk8 ---> Applying patches to openjdk8 ---> Configuring openjdk8 ---> Building openjdk8 Error: Failed to build openjdk8: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk8/openjdk8/main.log for details. Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug. Error: Processing of port sbt failed catap@Kirills-mini-m1 ~ %
To be honest I think that this is a major issue for new users who attempts to install sbt
or maven3
and move away from MacPorts.
comment:9 Changed 2 years ago by cooljeanius (Eric Gallager)
Cc: | cooljeanius added |
---|
comment:10 Changed 2 years ago by lilvadim (Vadim)
I have the same output while trying to install gradle
package. It was installed in my system before but then update started failing because of this issue and I decided to completely reinstall openjdk8
and dependents, but issue still appears.
(Air M1)
comment:11 Changed 2 years ago by breun (Nils Breunese)
I think it would be good to create a separate issue against openjdk8
for the disappeared ARM64 support. openjdk8
indeed used to support ARM64 when it was still a ports delegating to other ports, but I think this support was lost with the switch to build OpenJDK from source for openjdk8
.
Not a real solution, but maybe a workaround for now: can you remove openjdk
and install openjdk8-zulu
explicitly first and then install gradle
?
I can't change it back to
openjdk17
meta port but I can update thedbeaver-community
portfile to add support foropenjdk17
port.openjdk17
port builds from non-modified source code, thus providing a totally unmodified OpenJDK unlike any vendor. Moreover, I had changed from the openjdk meta ports to these type of openjdk ports as they are mentioned on official OpenJDK BSD port project for the oldopenjdk6
port (https://wiki.openjdk.java.net/display/BSDPort).