Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#61582 - [opencv] Add a symlink for Debian / Ubuntu oriented packages

Attached to Project: Arch Linux
Opened by Martin Roth (Captain_Rage) - Wednesday, 30 January 2019, 20:41 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 30 January 2019, 21:24 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Now that the opencv package had Java support added (much appreciated!) I have a nitpicky request to add a symlink* in order for Debian / Ubuntu oriented programs to be made aware of opencv.

*)
'ln -s /usr/lib/libopencv_java401.so /usr/lib/libopencv_java.so'
See: https://sikulix-2014.readthedocs.io/en/latest/newslinux.html#newslinux ('Getting the OpenCV support ready').

Rationale: A symbolic link has a minimal memory footprint and it would be practical to have it by default.

Additional info:
opencv 4.0.1-3

Steps to reproduce:
Run for example SikuliX and it will complain that it cannot find opencv, unless there is a pointer at /usr/lib/libopencv_java.so.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Wednesday, 30 January 2019, 21:24 GMT
Reason for closing:  Won't implement
Comment by Eli Schwartz (eschwartz) - Wednesday, 30 January 2019, 21:24 GMT
Why do you think this is automatically some sort of good idea because "the symlink is small and doesn't have a large memory footprint"? The memory footprint is the least possible significant thing about this...

- Hacking up a package to install non-upstream shared library names perpetuates unpredictability.
- Hacking up a package to install non-upstream shared library names implies you disagree with upstream's decision that this module should contain the version in the library name rather than the soname.
- Hacking up a package to install non-upstream shared library names just to be compatible with Debian makes no sense as this is not Debian and we don't need to be compatible with Debian.
- Hacking up a package to install non-upstream shared library names means that applications built against an older version will blindly see the newer version and try it, even though the two are not compatible. This is only okay on Debian because they never update past the old version...

And the more kludgy workarounds we add in our packaging, the less our package comes to resemble upstream intentions. We'd need to have a lot better reason to do this than "be like debian".

Loading...