Thank you for the fast reply! Does the installer actually use java for anything? This link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803717 has someone claiming success after removing the check, and I don't see anything obvious in the postinst that looks like it would invoke Java.
>From the "fail early" comment, it seems like they're failing during install because they expect failure at runtime, but in the case of offline builds of variant distros in a chroot, runtime will be a totally different environment that *will* have /proc. It's easy enough to work around, but it's fairly confusing, so at the very least, I think it deserves some documentation or a comment as to it's true purpose. On Sun, Jan 10, 2021 at 1:24 PM Florian Weimer <f...@deneb.enyo.de> wrote: > * Daniel Dunn: > > > In this file: > > > > > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/JB-jre-headless.postinst.in?h=openjdk-14 > > > > > > This code seems to still exist. It complicates installation in a chroot, > > > > such as for CustomPiOS. Do we still need it? It says things will change > in > > > > JDK7, but we've come a long way since then. > > > > # fail early. java currently uses tricks to find its own shared > > # libraries depending on the path of the binary. Will be changed > > # in OpenJDK7 > > if ! mountpoint -q /proc; then > > echo >&2 "the java command requires a mounted proc fs (/proc)." > > exit 1 > > fi > > $ eu-readelf -d /usr/bin/java > > Dynamic segment contains 36 entries: > Addr: 0x0000000000003d98 Offset: 0x002d98 Link to section: [ 7] > '.dynstr' > Type Value > […] > RUNPATH Library runpath: [$ORIGIN:$ORIGIN/../lib] > […] > > That $ORIGIN needs /proc/self/exe to resolve. >
