There's no explicit rule against it, but I do think it is sort of ugly and it's not exactly good practice... you can see how it caused a mess here... generally multiple packages building towards the same software are supposed to provide unique use cases that aren't handled by other variants yet, and typically -bin packages will repackage an upstream binary on the rationale that it is the version which is tested and supported by upstream -- and is usually standalone, without requiring external dependencies.
If this is just a matter of build times, I'm genuinely curious why it isn't a superior alternative, to simply host an unofficial repository containing a built version of the https://aur.archlinux.org/packages/swift package.
It's not as if I intentionally took a hammer to everyone's systems.
I think it would probably be a good idea to keep in mind that, whether accidental or not, manipulating the ld.so.conf path is always, without exception, a potential sledgehammer... and must therefore be treated with thoughtful care. It has the power to override /usr/lib, no less than installing an LD_LIBRARY_PATH or LD_PRELOAD to /etc/profile.d/
The ncurses breakage I can understand how it might not have been foreseen. But symlinking ICU is just wrong, every time someone does a partial update of their system and someone suggests symlinking the upgraded library soname, the support staff needs to yet again explain how this is a horrible idea and the whole reason sonames change is because they are incompatible, etc. etc. etc... and then there is a package which installs and relies on something like this??? Even if it did not leak into the global namespace and risk silently corrupting peoples' ICU-using applications, I would feel obligated to point out that swift itself would be using incompatible ICU symbols.
...
The corrupted soname may be because of https://github.com/NixOS/patchelf/issues/115 and is generally disappointing that patchelf doesn't perform as expected, but actually in retrospect I'm not sure you can modify an ELF to extend the size of a DT_NEEDED tag at all... not that this is useful insight when using it to exchange a single character in a NEEDED field for e.g. libalpm.so.11.0.1 (libcurl.so.4 -> libcurl.so.5) results in ldconfig: file ./libalpm.so.11.0.1 is truncated
All things considered symlinks into a private RPATH may indeed be the best option, but I would still advise you to link to ln -s ../../${lib}w.so.6 rather than risk swift breaking whenever ncurses 7 becomes a thing.
...
As long as the package has been fixed so it no longer stops peoples' systems from booting (albeit two weeks after the issue was reported), I guess I'm not going to force a deletion request for it. But as I said above, I guess I don't really see why it wouldn't be a better solution to host a prebuilt repository instead.
Pinned Comments