[raspberry] openhabian-config symlink aarch32 w/ arm

[meckiemac]

Hi,
I have a raspberry with unifi and openhab running. Unifi requires Java 1.8 too, but original oracle or the open-jdk. With some testing I got unifi also running with the zulu java installed by openhabian-config. It runs since 2 month without any issues.
Unifi uses jsvc to start the java processes. Jsvc checks on unusual places for java libraries. With symlinking the 2 "aarch32" directories to "arm" within the zulu jdk jsvc is now happy with the zulu jdk.
Is it possible to add the 2 symlinks in the install process of the jdk?

[meckiemac]

[19:52:33] root@raspberrypi:/opt/jdk/zulu8.40.0.178-ca-jdk1.8.0_222-linux_aarch32hf/lib# ls -la
total 35924
drwxrwxr-x 4 mongodb  122     4096 Feb 24 09:31 .
drwxrwxr-x 9 mongodb  122     4096 Jul 10  2019 ..
drwxrwxr-x 3 mongodb  122     4096 Jul 10  2019 aarch32
lrwxrwxrwx 1 root    root        7 Feb 24 09:31 arm -> aarch32
-rw-rw-r-- 1 mongodb  122 17811468 Jul 10  2019 ct.sym

And another nice help would be an entry in the "update-alternatives" for finding the jdk easier.

[mstormi]

openHABian is not meant to be a basis for anything to run on top other that what it brings, and Unifi is not part of that.
You are free to add and run anything you like (or to create that link yourself) , but then you need to (manually) do that yourself. We will not implement that in openHABian for any user to use.
If you contribute a PR we will consider adding this to openHABian although in this case I don't think we would want to add Unifi as new functionality to openHABian as we just decided to focus on stabilizing and sanitizing rather than adding new features. Please understand that to support new features means we need to test them ourselves, too, for its whole lifespan.

[meckiemac]

What about taking Unifi out of the focus and just do a proper registration of the jdk in the OS with update-alternatives, like all the other jdk and jre and implement a small fix for other java tools like jsvc?
What is a PR? The little changes I can paste here as soon I have to redo them with the next update ;-).

[mstormi]

What about taking Unifi out of the focus and just do a proper registration of the jdk in the OS with update-alternatives, like all the other jdk and jre and implement a small fix for other java tools like jsvc?

I know what you're after but this is not how it's supposed to work. There is no need in openHABian for update-alternatives to work because the installed java works with everything that is part of openHABian, and openHABian will not support anything else to install on top like Unifi or whatever other java app which would need a working update-alternatives.
openHABian is NOT a general purpose Linux distro. It's an appliance to ONLY implement what it brings, with an intentional minimum in flexibility of what a user can/needs to choose from.
Again: you are free to change and install on top anything you like. But from there on you're on your own, i.e. no warranties.
And besides that, to speak frankly I wouldn't see the benefit of a generic implementation.
Why don't you simply create those links when you upgrade java (which is maybe twice a year at most) and you're set ? Yes that question is of rhetoric nature, sorry.

What is a PR? The little changes I can paste here as soon I have to redo them with the next update

Pull Request. It means to do the coding yourself and offer the result to us for integration into openHABian.

[ThomDietrich]

Hey all,
I want to rephrase what Markus said, which can be understood in the wrong way. Of course openHABian is based on Raspbian and as such a normal Linux system on which a user can decide to install other software in parallel to what is officially offered by openHABian.
The openHABian team tries to provide everything as standard as possible to enable that! That said: Of course a stable and clutter-free openHAB base system is the focus of development. Every additional change just bloats the project and might introduce errors in the long run.

@meckiemac Regarding Unifi and Java: The different java distributions and ways they can be set up are manifold and the minor differences are painful to deal with. Adding the arm symlink for update-alternatives sounds reasonable but could have unwanted side effects, e.g. how certain architectures behave. This would be hard to test and debug. Do you have a source (e.g. in the Zulu forum) that discusses this? Why doesn't Zulu provide the target out of the box?
@BClark09 What's your take on this?

[BClark09]

Hi all,

I noticed this was somewhat discussed on the community forums.

I'm not sure why the paths jsvc looks at are different to what is installed. But I agree that we'd need to be careful with adding symlinks like this, it'd need to be tested thoroughly first (e.g. does it break other architectures?). IMO the current JDK install process is getting rather complicated already.

I also wonder, that when we inevitably transition to Java 11+ that we can take the chance to simplify the process and return back to openJDK (perhaps through an AdoptOpenJDK install). We would need to make sure that the issues that @kaikreuzer points out are resolved first though. AFAIK, openJDK-11 contains a JIT compiler.

[mstormi]

@BClark09 let's not discuss Java options in different places and in a mixed round with users.
I suggest we continue in https://github.com/orgs/openhab/teams/refocus-ian/discussions/6

[meckiemac]

After spending some time, I think it should be separated into 2 problems. One is when Zulu gets installed it should also be registered right as an available Jdk version. The importance to conflict not with other jdk installs can set to a low value.
The jsvc behaviour or the missing symlinks within the jdk is either a zulu or a jsvc issue. The workarounds are known.

[ThomDietrich]

Thanks all.

Java 11: I think we can agree that we will stay with Zulu now and whatever might change because of openHAB3 is far away.

jsvc: What I get from the discussion is that we are not certain whether the addition might bring unwanted side effects and that it is not essential to a wider user base.
@meckiemac from what you wrote I understand that the reason why this issue is so unpleasant for you is that java is updated on every openHABian update. This is a bug currently tracked in a ticket @mstormi will please reference in a comment :) After this is fixed java will not be overwritten every update and ideally your symlink is never removed. I believe you'd be pleased with this? ;)

[mstormi]

when Zulu gets installed it should also be registered right as an available Jdk version.

It is registered:

[09:46:09] openhabian@openhabianpi:~/openhabian$ update-alternatives --display java
java - automatischer Modus
  beste Version des Links ist /opt/jdk/zulu8.40.0.178-ca-jdk1.8.0_222-linux_aarch32hf/bin/java
  Link verweist zur Zeit auf /opt/jdk/zulu8.40.0.178-ca-jdk1.8.0_222-linux_aarch32hf/bin/java
  Link java ist /usr/bin/java
/opt/jdk/zulu8.40.0.178-ca-jdk1.8.0_222-linux_aarch32hf/bin/java - Priorität 1083000
[09:53:40] openhabian@openhabianpi:~/openhabian$

You can run update_alternatives at any time yourself if you want to change what java points to or want to register additional binaries such as jsvc .

[mstormi]

"won't fix" means not to add symlinks as requested BUT I assume #723 is your real problem and #819 will fix it so I've left this issue open and merging #819 will auto-close it.
BTW this whole issue is a good example for the XY problem.