Arch Linux User Repository

==> ERROR: Failure while downloading https://rpmfind.net/linux/fedora/linux/updates/testing/31/Everything/x86_64/Packages/s/swift-lang-5.1.1-0.1.20191004git4242edd.fc31.x86_64.rpm Aborting...

The RPM is not found at this address

@Darnor Oof nice catch, just fixed it.

Please update the swift-lang-runtime source to point to:

https://rpmfind.net/linux/fedora/linux/updates/testing/31/Everything/x86_64/Packages/s/swift-lang-runtime-5.1.1-0.1.20191004git4242edd.fc31.x86_64.rpm

and replace the '201a526342cc72ff839f2caf17d3b29ac1f4248be7d6621dead4683adee9c171' checksum with '2c3da0448f27e88c1cdb6af52e68a6643820d545723eba6275b62a7cda6bbd59'

Finally updated the package again, sorry for the huge delay. I also have an idea to finally drop libexec, so look forward to that SOON(tm).

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.

Okay, package updated, apologies for the initramfs mess. I separated the exported libraries outside the ldconfig paths and triple-checked them to make sure nothing was unintentionally seeping in.

Unfortunately, this now means that the package is a lie, as a -bin package that does not actually use the upstream "Official binary builds" has no excuse to exist.

Is there a set rule for this? It's not in the AUR guidelines, and until swift maybe gets in community, not everyone wants to spend the time compiling it.

It is also the source of a very major problem -- you have done vastly inappropriate things to the ld loader in order to lie about the binaries, introducing deadly libicu symlinks to the entire user ecosystem rather than depending on https://aur.archlinux.org/packages/icu62 for the incompatible libraries that don't work at all.

I will admit I did not realize icu62 was on the AUR.

And rather than assassinating peoples' initramfs with broken and inadvisable ncurses breakage, you should have used patchelf --replace-needed to redirect the ncurses linkage.

I know about patchelf --replace-needed, but it breaks ldconfig due to a glibc bug. I did some research and was finally able to track it down and report it, but until then I had to use hacks to keep the ncurses symlinks out of the ldconfig path.

Fedora doesn't build statically against icu or ncurses, so you end up breaking not only the package, but also peoples' systems, trying to sledgehammer it into working.

I will also admit, the system breakage was...very, very bad, but at the same time it was a complete accident due to the ldconfig paths. It's not as if I intentionally took a hammer to everyone's systems.

Anyway, give me one reason why this package should not be deleted.

Swift takes a really freaking long time to build, and not everyone who wants to build it might be able to.

I'll happily take this down if we get Swift in community, but until then this does prove useful for some people.

In addition, the Fedora Swift binaries are now used over the Ubuntu ones, which means that no more ld hacks are needed, and the amount of ugly changes to the binaries has been significantly dropped.

Unfortunately, this now means that the package is a lie, as a -bin package that does not actually use the upstream "Official binary builds" has no excuse to exist.

It is also the source of a very major problem -- you have done vastly inappropriate things to the ld loader in order to lie about the binaries, introducing deadly libicu symlinks to the entire user ecosystem rather than depending on https://aur.archlinux.org/packages/icu62 for the incompatible libraries that don't work at all.

And rather than assassinating peoples' initramfs with broken and inadvisable ncurses breakage, you should have used patchelf --replace-needed to redirect the ncurses linkage.

But this is precisely why it is completely wrong to create -bin packages for open-source code that merely download some other linux distribution's unofficial builds. There is zero utility of using this over the one that builds, properly, from source. The only reason -bin packages make sense at all is when upstream developers provide standalone binaries that are meant to work out of the box and which they test against for source code regressions. None of that is the case here -- Fedora doesn't build statically against icu or ncurses, so you end up breaking not only the package, but also peoples' systems, trying to sledgehammer it into working.

...

Anyway, give me one reason why this package should not be deleted.

Yes, Removing this line from swift-lang.conf and running ldconfig fixes the issue; /usr/lib/libncursesw.so.6 is used again for the initramfs.

s3lph: Oh wow, that's really bad... Does it work if you remove /usr/lib/swift/linux from /etc/ld.so.conf.d/swift-lang.conf when building the initramfs ?

The latest version (4.2.1-1) for some reason breaks my boot process after the next mkinitcpio after installation.

/usr/lib/swift/linux/libncursesw.so.6 seems to be put into the initramfs instead of /usr/lib/libncursesw.so.6. However, /usr/lib/swift/linux does not seem to end up in the library search path in the initramfs, and my lvm volumes can't be activated since the pvscan binary used by the lvm2 hook is linked against libncursesw.so.6, which is not found.

Running pvscan with a manually preloaded /usr/lib/swift/linux/libncursesw.so.6 in the recovery shell followed by manually mounting the rootfs allowed me to continue booting. Uninstalling this package followed by a mkinitcpio resolves the issue.