Issue #2367: swift-lang packaging; may I install everything /usr/libexec/swift - fesco

fesco

#2367 swift-lang packaging; may I install everything /usr/libexec/swift

Closed: Duplicate 4 years ago by churchyard. Opened 4 years ago by tachoknight.

Aloha-

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.

Thanks,

Ron

decathorpe commented 4 years ago

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?

churchyard commented 4 years ago

Should this be a FPC question?

decathorpe commented 4 years ago

Oops, I didn't even notice - I only opened the link from the notification email and assumed it was filed against FPC because of the topic :) I agree, this is probably more a question for the Packaging Committee

tachoknight commented 4 years ago

Oh, sorry; where can I open this issue with Packaging Committee?

tachoknight commented 4 years ago

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?

Yes, I was planning on also redoing the way the versioning is handled; it was a consequence of when I was first trying to get the package approved and I had (still have) automated scripts that were building and packaging the latest snapshot every night.
I'm also sorry about the changelog issues; I run parallel builds of the Swift package on the current release, the next release, master, etc.; and they're all in separate git branches. When doing an official release the changelogs would not match up. This I am also planning on fixing.

churchyard commented 4 years ago