[pkg] fix: add jri-N-ev3 self-dep to fix ca-certificates-java #64
Conversation
With this, new clean installations should have working system-wide java ca certificates. This is a non-invasive alternative to #61 + #62. The fix is likely based on a trick for making dpkg configure this package first before configuring other packages that depend on it. The downside of this is that current installations will not get fixed. They will still potentially have corrupted trust store from previous failed installations. I don't know what the state of ev3dev is, but if the package installation fails even in the ev3dev base image, then *all* EV3 installations will have corrupted trust store. The trust store can be un-corrupted by completely removing and reinstalling ca-certificates-java. This is quite a heavy operation for EV3, so this is a reason why the other solution might be preferred.
|
Yep, unfortunately the |
|
I have realized that indeed, the first post of adoptium/installer#105 mentions the likely cause - the |
|
According to https://salsa.debian.org/java-team/ca-certificates-java/-/merge_requests/3#note_92769, the self-dep trick actually works. |
This also needs to be fixed by a separate upload of |
|
Continuing in ev3dev-lang-java/ev3dev-lang-java#731 |
|
This is another alternative to another PR. I will contact you tomorrow to talk about the alternatives. Cheers |
|
Solution rejected in favor of #61 |
|
reopening |
|
I am going to close this PR too. |
2 participants
With this PR, new clean JRI installations should have working system-wide java ca certificates. This is a non-invasive alternative to #61
+ #62(orthogonal PR).The problem is that ca-certificates-java depend on jri-N-ev3 when it is not yet ready; see #61 (comment) for the console output.
The fix is likely based on a trick for making dpkg configure this package first before configuring other packages that depend on it.
The downside of this solution is that pre-existing installations will not get fixed. They will still potentially have corrupted trust store from previous failed installations. I don't know what the state of ev3dev is, but if the package installation fails even in the ev3dev base image, then all EV3 installations have the trust store corrupted.
The trust store can be un-corrupted by completely removing and reinstalling ca-certificates-java. This is quite a heavy operation for EV3, so this is a reason why the other solution might be preferred.
EDIT: see comments in ev3dev-lang-java/ev3dev-lang-java#731 for further analysis