Build deb packages

[aahlenst]

This is work in progress and not ready to merge. But I'm looking for feedback before I invest time going into the wrong direction.

As it stands, the Makefile produces a deb package for Ubuntu 18.04 with the help of fpm. As input it uses a tarball release of OpenJDK 11 for x64. The Makefile isn't pretty because the focus was on producing a good deb package with post install and removal scripts. So far, it installs and uninstalls fine and integrates well with update-alternatives and update-java-alternatives. It can be installed side by side with other JDK distributions like the one provided by the operating system or Azul Zulu.

There's still a lot of work to do:

• Build additional versions of OpenJDK.
• Support additional platforms besides x64.
• Test on additional versions of Ubuntu and Debian.
• Improve parameterization.

Questions in no particular order:

• Are you interested in something like that?
• Should the package be split in a JRE and a JDK package like it's currently done by Debian and Ubuntu? I see some problems there looking at the current JDK 11 builds. There are some conflicting files like lib/modules that are present in both the JRE and JDK but are not identical. So far, the only option I see would be to package both separately and declare them as conflicting packages. Azul only provides the full JDK, I haven't checked what Amazon is doing with Corretto.
• What should I use as input? The other installers use a path to a directory containing an OpenJDK build.
• How is this going to be distributed? Should uploading the results be part of the package build or is this a separate topic? In my opinion, the packages should end up in a proper repository (Artifactory, Bintray, something like that) so that they can be installed and updated via apt.
• Is fpm okay? I chose it because it supports more package formats than the gradle-ospackage-plugin that is used by Amazon for Corretto and it's less of a hassle than the packaging tools provided by the Linux distributions.
• How to test on other platforms? I have no access to some platforms supported by AdoptOpenJDK.
• Any opinions regarding the naming of the files and directories?

As soon as this in proper shape, adding support for rpms and other formats should hopefully not be that much work.

Remaining tasks:

• Test cross platform package build (e.g. deb can be built on CentOS without additional packages)
• Wrap build process in Gradle
• Rename artifacts/paths to match OS default packages, other AdoptOpenJDK installers
• Build OpenJDK 8, 9, 10, 11, 12
• Build Hotspot and OpenJ9
• Define supported Ubuntu and Debian versions and build for them
• Build on all supported architectures
• Parameterize build
• Test packages on all supported Ubuntu/Debian/architecture/JVM combinations

[gdams]

@aahlenst thanks for your work! can we setup a call to go through this some time? CC @AdoptOpenJDK/installer

[aahlenst]

Should be doable. What do you consider a call (chat or real voice)?

[gdams]

a call is probably best :)

[dennisl]

We are very interested in this. If there is any way for us to help with testing, please let us know.

[aahlenst]

The tooling is now capable of building packages of OpenJDK 11 with Hotspot or OpenJ9 on AMD64. I've tested on Ubuntu 18.04.

If anyone wants to give it a try:

1. Download and unpack the tarball for Linux.
2. Change to the linux directory and run Gradle according to the recipes below.

For Hotspot:

./gradlew clean build \
    -PJDK_DISTRIBUTION_DIR=/path/to/jdk-11.0.2+9 \
    -PJDK_MAJOR_VERSION=11 \
    -PJDK_VERSION="11.0.2+9" \
    -PJDK_VM=hotspot \
    -PJDK_ARCHITECTURE=amd64 \
    -PDEB_JINFO_PRIORITY=1102

For OpenJ9:

./gradlew clean build \
    -PJDK_DISTRIBUTION_DIR=/path/to/jdk-11.0.2+9_openj9-0.12.1 \
    -PJDK_MAJOR_VERSION=11 \
    -PJDK_VERSION="11.0.2+9" \
    -PJDK_VM=openj9 \
    -PJDK_ARCHITECTURE=amd64 \
    -PDEB_JINFO_PRIORITY=1102

The Debian packages can be found afterwards in linux/deb/build.

If you feel adventurous, you can try it with another architecture by downloading the appropriate tarball and changing JDK_ARCHITECTURE to whatever value Debian assigned to that architecture.

Both OpenJ9 and Hotspot can be installed side by side.

[aahlenst]

From my side we're good to go here. The README should outline what's possible/supported and what not. I tested what I could on amd64.

Stuff that needs to be dealt with at a later stage:

• Setting up a repository and uploading to it.
• Automatic verification of the packages.
• Packaging rpms.

[gdams]

@dennisl feel free to run some tests on https://ci.adoptopenjdk.net/view/work%20in%20progress/job/andreas-deb-job/10/artifact/linux/deb/build/adoptopenjdk-11-hotspot_11.0.2+9-1_amd64.deb and let us know what you think!

[gdams]

running the following simple test:

apt-get update
wget https://ci.adoptopenjdk.net/view/work%20in%20progress/job/andreas-deb-job/10/artifact/linux/deb/build/adoptopenjdk-11-hotspot_11.0.2+9-1_amd64.deb
dpkg -i adoptopenjdk-11-hotspot_11.0.2+9-1_amd64.deb 
apt-get install -f
dpkg -i adoptopenjdk-11-hotspot_11.0.2+9-1_amd64.deb 
java -version #check it outputs the correct adoptopenjdk version

• debian 8
• ubuntu 14.04
• ubuntu 16.04
• ubuntu 18.04

[dennisl]

Thank you so much!

We tried to install the deb-file you provided and it worked fine. Since we are running on Java 8 we also tried to build our own deb-file for OpenJDK 8 with hotspot for amd64. We just followed the instructions and ended up with a deb-file that installed without a problem.

One thing to note is that if you install OpenJDK 8 after OpenJDK 11, the current java version will still be OpenJDK 11. I'm not experienced when it comes to creating deb-files, but I guess it has to do with the priority parameter. To switch you need to use:
update-alternatives --config java

All tests were done on Ubuntu 18.04.

[aahlenst]

Yeah, if you install OpenJDK 11 first and OpenJDK 8 later OpenJDK 11 will still be the default. To change the default JDK, use update-java-alternatives. If you just use update-alternatives, it will only change the single executable you mention. So you might end up with a Java 8 java and Java 11 javac.

[gdams]

Yeah that's the same behaviour as the homebrew casks

[dennisl]

Thanks @aahlenst !

[aahlenst]

Superseded by #79.