#966 swift-lang packaging; may I install everything /usr/libexec/swift
Closed: accepted 2 years ago by james. Opened 2 years ago by tachoknight.

(I had originally opened this issue with the FESCo here and was redirected to open it with the packaging committee, so I'm posting the original message below verbatim for anyone who wouldn't have seen it in before.)


Swift 5.2.1 was released and, as it currently stands, cannot be updated on Fedora because the REPL does not work. I have documented my issues here.
The biggest issue is that, fundamentally, the Swift toolchain uses hard-coded paths and expects things to be in specific locations relative to other programs (and libraries, it turns out). This has been an enormous headache for me because I have had to, for every major version, redo my patches to force certain binaries to look in other locations. This extremely brittle process has finally broken with 5.2 as I'm currently unable to find and patch all the new places the codebase expects to find other things.

What I'm proposing is to permit the swift-lang package to install the Swift toolchain in /usr/libexec/swift, with two symlinks for swift and swiftc in /usr/bin. I have tested this and everything works correctly, does not interfere with the LLVM/LLDB/Clang packages (which is the reason why I had to relocate certain binaries like lldb in the first place) and makes maintaining the swift-lang package much easier.

As far as putting everything in /usr/libexec/swift, I figure that is the proper place because 99% of the Swift package is not meant to be invoked by the user (for example, the lldb binary that is included with the Swift is custom-built for the Swift REPL). The only two exceptions, swift and swiftc, would be, as mentioned above, symlinks in /usr/bin and thus the user can use the Swift REPL, and compile Swift programs, without needing to interact with any other part of the toolchain.

As a corollary to the proposal, I would also like to drop the swift-lang-runtime sub-package; the goal was to allow Swift-compiled programs the ability to run without the complete toolchain installed. This has proven to be an issue insofar as the Linux version of Swift does not have ABI stability; no version of a compiled Swift program has worked on a newer version of the runtime and is not a critical path issue for the Swift project.

So the TL;DR;
1. I would like to move the entirety of the Swift package into a new location, /usr/libexec/swift and place two symlinks for the main binary in /usr/bin (swift and swiftc)
2. Remove the swift-lang-runtime subpackage.

I am committed to maintaining and providing Swift for Fedora users, but given the cadence of releases, along with the need to keep Swift working alongside Clang/LLVM/LLDB which can be many versions ahead of the Swift ones, keeping the package up to date has morphed from taking too much of my time to an exercise in frustration. By repackaging it as described above, it will make maintaining Swift so very much easier with no loss of functionality to the end user.



I already had commented on the FESCo issue, I'll paste my reply below ...

This sounds like a reasonable approach to me, given that it's already difficult enough to package swift.

It's not directly related to this request, but I'd like to see correctly versioned packages at some point. For -RELEASE builds, the Release tag should be an integer followed by %{?dist}. Values starting with 0.N and containing additional git hash / git date information are reserved for snapshot builds.

If you switch between git snapshots and release builds often, you could even automate this by one or two simple macros.

You're also completely rewriting the changelog with some commits - why?

I have build a new package that fixes the versioning issue as well as provides the new hierarchy; works great! I'm currently testing upgrades from the current version (5.1.5) to 5.2.1. I also fixed my build infrastructure to not add lines to the %changelog section so there will be a single path of %changelog entries, explicitly written by me, going forward.

I have successfully built and tested the new packaging on a test machine and everything works great! I have also run some scratch builds on Koji for all the current platforms.


/usr/libexec : Binaries run by other programs (optional)

/usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/libexec.

That fits perfectly for what you describe. +1

We quickly discussed this at the open floor part of this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-04-09/fpc.2020-04-09-16.00.txt):

  • Open Floor (geppetto, 17:00:14)
  • ACTION: 966 request to use /usr/libexec/swift seems fine to everyone
    (geppetto, 17:05:37)

Metadata Update from @james:
- Issue close_status updated to: accepted
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.