| Summary: | dev-java/openjdk-bin-11.0.7_p10 broken cacerts symlink | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Anton Bolshakov <anton.bugs> |
| Component: | Current packages | Assignee: | Georgy Yakovlev <gyakovlev> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | java, jstein |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Anton Bolshakov
2020-04-22 08:38:23 UTC
on my systems symlink is NOT broken for both versions and points like this: > pwd > /opt/openjdk-bin-8.252_p09/jre/lib/security > cacerts -> ../../../../../etc/ssl/certs/java/cacerts > file cacerts > cacerts: symbolic link to ../../../../../etc/ssl/certs/java/cacerts > file -L cacerts > cacerts: Java KeyStore > pwd > /opt/openjdk-bin-11.0.6_p10/lib/security > cacerts -> ../../../../etc/ssl/certs/java/cacerts > file cacerts > cacerts: symbolic link to ../../../../etc/ssl/certs/java/cacerts > file -L cacerts > cacerts: Java KeyStore is your /opt somehow specially mounted or is a symlink? or maybe anything else special about filesystem layout? We used to create absolute symlinks and it was easier to follow that this multi-level madness, but such are rules. Correct, my /opt is a symlink: /opt -> /data/opt I’ll see what I can do to make a bit more robust or switch back to prefix + absolute path, for now please use workaround, I’ll need to speak with QA guys about absolute symlink destinations. It's not a surprise, that any other packages installed in opt with relevant symlinks are broken too. Here is what I have installed: ./linkchecker /opt/ /opt/zoom/libturbojpeg.so -> ../../usr/lib64/libturbojpeg.so /opt/zoom/libmpg123.so -> ../../usr/lib64/libmpg123.so /opt/firefox/browser/plugins -> /usr/lib64/nsbrowser/plugins /opt/thunderbird/plugins -> /usr/lib64/nsbrowser/plugins This but should be reassign to relevant parties. I think you should really try to work-around it locally, there's no good way to work support it in ebuild/eclass/portage. Probably maintainers just going to ignore, as supporting every possible filesystem layout is hard. I've seen bugs like this closed WONTFIX. instead of symlink you can use bind mount. you can bind mount anything anywhere, even files. so this entry in fstab /data/opt /opt none bind 0 0 will do the same as symlink, but without symlink dereference problem and/or wrong levels with relative symlink. before doing above don't forget to remove /opt symlink and create an empty directory instead. you can do same with individual files as well like mount -o bind /etc/resolv.conf /mnt/gentoo/etc/resolv.conf will bind a single file. Closing. also I think bind-mounting will solve your current symlink, you will not even need to reinstall packages. I suspect a problem is deeper. Portage should not require a specific FS system. Other users my have symlink the entire /usr for example. It would break hard the OS. I expect a proper resolution. feel free to open generic bug and link this one or send an email to gentoo-dev@lists.gentoo.org for more discussion. |
