I cannot create an ebuild for dev-python/unrardll that links to libunrar: ``` src/unrardll/wrapper.cpp:19:10: fatal error: unrar/dll.hpp: No such file or directory 19 | #include <unrar/dll.hpp> | ^~~~~~~~~~~~~~~ compilation terminated. error: command '/usr/bin/x86_64-pc-linux-gnu-gcc' failed with exit code 1 * ERROR: dev-python/unrardll-0.1.7::personal failed (compile phase): ``` The upstream software expects headers in /usr/include/unrar/*.hpp but the ebuild currently installs them to /usr/include/libunrar6 and creates a /usr/include/libunrar symlink. I think it would make sense to create a /usr/include/unrar symlink as well.
For a bit of comparison: - arch uses unrar/dll.hpp - freebsd uses libunrar/dll.hpp - macports uses unrar/dll.hpp - opensuse uses unrar/dll.hpp - netbsd uses dll.hpp, very brave of them - rpmfusion / redhat uses unrar/*.hpp - voidlinux uses unrar/dll.hpp Most people do not seem to distribute all hpp files, only one of them. I haven't spotted all that many people distributing it at all -- and gentoo seems to be the only one using a versioned header directory. Consensus seems to be usually to use "unrar".
Created attachment 873292 [details, diff] app-arch/unrar: fix symlinked header shenanigans Here is an attempt to fix this by standardizing on "unrar" as the canonical location. It's difficult to tell what other software depends on libunrar vs depends on the unrar command-line tool. I found two: - media-gfx/ahoviewer, build system probes for both "unrar" and "libunrar" in various locations - sys-fs/rar2fs, build system checks for ./unrar but accepts --with-unrar="${ESYSROOT}"/usr/include/libunrar in the ebuild. I will just drop libunrar6, no one uses it. Also, I can't actually make it work, because of bug 834600.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=755c12b726acdb1b350ee24608b43d8f36eafdd1 commit 755c12b726acdb1b350ee24608b43d8f36eafdd1 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2023-10-23 03:31:40 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-10-24 18:34:48 +0000 app-arch/unrar: fix symlinked header shenanigans UnRar is horrible proprietary Windows-oriented software, yes yes yes we know. It's nonstandard and the build system is a mess. It doesn't version the library soname, doesn't install headers, doesn't uninstall the files it installs, etc. Every distributor of it hacks around this differently, but there are a couple things that it would be good to be consistent with. In particular, a stable name is needed for: - including the header - passing link args to the compiler The latter works fine, but the former does not. There's a rough consensus to use "unrar/" to install headers, and other projects rely on that (or fall back to "libunrar/"), but we do not install there, and the place we do install to is not used even in ::gentoo. Start installing to "unrar/" instead. This allows some software to work that formerly did not, and should still work everywhere else that was looking for "libunrar/" as that is kept as a compat symlink. Closes: https://bugs.gentoo.org/916036 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> app-arch/unrar/unrar-6.2.12-r1.ebuild | 79 +++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+)
