Packaging
----------
1. This is a derivative of the openjdk-17 source package [1]. Though it contains additional dependencies and a different upstream code repository, the Debian packaging code is borrowed from the openjdk-17 and modified to suit openjdk/crac needs.
2. The binary openjdk-17-crac-* packages may be installed alongside the vanilla openjdk-17-* packages. They may be configured using `update-alternatives --config java`.
3. I have proposed vendoring in three dependencies and here are the rationales:
googletest: openjdk-17 also vendors in a specific version of googletest because it's upstream [2] uses it as a test-dependency. Because the openjdk-17-crac upstream [3] is also based upon the openjdk-17 upstream and we need the same version of googletest vendored in.
crac-criu: The checkpoint/restore functionality in openjdk-17-crac is driven by criu [4]. We have a 'criu' package in universe[5]. But what the openjdk/crac project uses is a significantly modified version of criu, named crac-criu [6]. Given that crac-criu binaries are "specialized criu binaries" for the openjdk/crac project, they are unlikely to have an independent identity in the Ubuntu archive. I hence thought it is better to vendor in this dependency. I have updated the debian/copyrights file to include the criu licenses.
lz4: Things get complicated here. The upstream crac-criu code pulls in a specific version of lz4 (which happens to be their last release) as a 'git submodule' [7]. Along with the static liblz4.a, the upstream crac-criu Makefile also builds another liblz4io.a from a specific object file, and in turn links these two archives into the crac-criu binaries [8]. I think this will be difficult to emulate by using lz4 as a builddep or through Built-Using (which I haven't explored much). I have vendored-in the latest official lz4 release and included the relevant licenses in the debian/copyrights file.
Maintenance
-----------
1. The openjdk-17-crac upstream [3] will have the latest JDK 17 security updates [2] augmented with openjdk/crac patches from [9]. For now, it includes security/CVE fixes that the April 2024 security updates of JDK 17. I intend to keep rebasing the openjdk/crac patches to the latest JDK 17 security updates on a quarterly basis (which is the openjdk project's cadence).
2. The crac-criu upstream [6] has specialized crac patches based upon checkpoint-restore/criu [10]. The latter exists in universe and has been stable over the last year. However, in the case of any CVEs being reported/fixed in checkpoint-restore/criu, I intend to bring them over to crac-criu as soon as they are published upstream.
Suitability
-----------
1. The licenses and copyrights of all vendored dependencies have been included in the debian/copyright file.
Some comments that might help in the review.
Packaging
----------
1. This is a derivative of the openjdk-17 source package [1]. Though it contains additional dependencies and a different upstream code repository, the Debian packaging code is borrowed from the openjdk-17 and modified to suit openjdk/crac needs.
2. The binary openjdk-17-crac-* packages may be installed alongside the vanilla openjdk-17-* packages. They may be configured using `update- alternatives --config java`.
3. I have proposed vendoring in three dependencies and here are the rationales:
googletest: openjdk-17 also vendors in a specific version of googletest because it's upstream [2] uses it as a test-dependency. Because the openjdk-17-crac upstream [3] is also based upon the openjdk-17 upstream and we need the same version of googletest vendored in.
crac-criu: The checkpoint/restore functionality in openjdk-17-crac is driven by criu [4]. We have a 'criu' package in universe[5]. But what the openjdk/crac project uses is a significantly modified version of criu, named crac-criu [6]. Given that crac-criu binaries are "specialized criu binaries" for the openjdk/crac project, they are unlikely to have an independent identity in the Ubuntu archive. I hence thought it is better to vendor in this dependency. I have updated the debian/copyrights file to include the criu licenses.
lz4: Things get complicated here. The upstream crac-criu code pulls in a specific version of lz4 (which happens to be their last release) as a 'git submodule' [7]. Along with the static liblz4.a, the upstream crac-criu Makefile also builds another liblz4io.a from a specific object file, and in turn links these two archives into the crac-criu binaries [8]. I think this will be difficult to emulate by using lz4 as a builddep or through Built-Using (which I haven't explored much). I have vendored-in the latest official lz4 release and included the relevant licenses in the debian/copyrights file.
Maintenance
-----------
1. The openjdk-17-crac upstream [3] will have the latest JDK 17 security updates [2] augmented with openjdk/crac patches from [9]. For now, it includes security/CVE fixes that the April 2024 security updates of JDK 17. I intend to keep rebasing the openjdk/crac patches to the latest JDK 17 security updates on a quarterly basis (which is the openjdk project's cadence).
2. The crac-criu upstream [6] has specialized crac patches based upon checkpoint- restore/ criu [10]. The latter exists in universe and has been stable over the last year. However, in the case of any CVEs being reported/fixed in checkpoint- restore/ criu, I intend to bring them over to crac-criu as soon as they are published upstream.
Suitability
-----------
1. The licenses and copyrights of all vendored dependencies have been included in the debian/copyright file.
[1] https:/ /launchpad. net/ubuntu/ +source/ openjdk- 17 /github. com/openjdk/ jdk17u /github. com/canonical/ openjdk- 17-crac /criu.org/ Main_Page /launchpad. net/ubuntu/ +source/ criu /github. com/canonical/ crac-criu /github. com/canonical/ crac-criu/ blob/crac/ Makefile# L250 /github. com/canonical/ crac-criu/ blob/crac/ Makefile# L253 /github. com/openjdk/ crac /github. com/checkpoint- restore/ criu
[2] https:/
[3] https:/
[4] https:/
[5] https:/
[6] https:/
[7] https:/
[8] https:/
[9] https:/
[10] https:/