#945 Requesting Conflict evaluation between swift-lang and llvm
Opened 2 months ago by tachoknight. Modified 2 months ago

Aloha-

I package Apple's Swift programming language for Fedora (swift-lang) and it is based on LLVM, but its own LLVM, with its own clang, lldb, etc. The Swift version of these binaries cannot coexist with the llvm package because of name clashes in /usr/bin, and the Swift package cannot use the binaries from the LLVM package because they are not built knowing anything about Swift. The LLVM binaries provided by the Swift package (e.g. clang) are full-featured so it's possible to use them for non-Swift development.
I have fixed this issue by patching the Swift source to look in other locations (e.g. /usr/libexec/swift-lldb) but this means maintaining a fair number of patches that have to be reworked every time a new version of Swift is released by Apple.

I was wondering if it would be possible to consider allowing swift-lang to have a conflict with llvm so that only one can be installed at a time; "regular" LLVM users would not be inconvenienced and folks who install Swift would get everything they need in the regular (e.g. /usr/bin) locations and could still do C and C++ work.

I am hoping to get Apple to recognize Fedora as an "official" Linux flavor of Swift, with the added benefit of being able to install via DNF, but relying on patches to put binaries into different locations would be a tough sell.

Thanks for considering this,

Ron (FAS user tachoknight)


I guess it does not work with Fedora's llvm/clang? Is it fork with bunch of patches or just different version or?

It does not work with Fedora's llvm/clang; that was the first thing I tried. It was discussed on the Swift forums (https://forums.swift.org ... sorry I can't find the direct link) that all the programs must be built and packaged together. Swift uses a fork of the LLVM project and I have not read any direct information that there is an attempt to push the changes upstream.

Swift is also using a different version; the official Clang is at 9.0.0 (/usr/bin/clang), while the one that is built and provided by Swift (hidden away in /usr/libexec/swift-lldb) is 7.0.0.

What I worry about is that swift would then provide /usr/bin/clang etc. but I guess this is not something our packages depend on:

$ for exe in $(repoquery --repo=koji -l swift-lang | grep /usr/libexec/swift-lldb/ | sed s@libexec/swift-lldb@bin@); do echo $exe; repoquery --repo=koji{,-source} --whatrequires $exe 2>/dev/null; echo; done
/usr/bin/clang

/usr/bin/clang++

/usr/bin/clang-7

/usr/bin/clang-cl

/usr/bin/clang-cpp

/usr/bin/clangd

/usr/bin/lldb

/usr/bin/lldb-argdumper

/usr/bin/lldb-instr

/usr/bin/lldb-mi

/usr/bin/lldb-server

/usr/bin/lldb-vscode

/usr/bin/repl_swift

/usr/bin/swift

For reference, this is what would swift-lang need to conflict with:

$ for exe in $(repoquery --repo=koji -l swift-lang | grep /usr/libexec/swift-lldb/ | sed s@libexec/swift-lldb@bin@); do echo $exe; repoquery --repo=koji{,-source} --whatprovides $exe 2>/dev/null; echo; done
/usr/bin/clang
clang-0:9.0.1-1.fc32.x86_64

/usr/bin/clang++
clang-0:9.0.1-1.fc32.x86_64

/usr/bin/clang-7

/usr/bin/clang-cl
clang-0:9.0.1-1.fc32.x86_64

/usr/bin/clang-cpp
clang-0:9.0.1-1.fc32.x86_64

/usr/bin/clangd
clang-tools-extra-0:9.0.1-1.fc32.x86_64

/usr/bin/lldb
lldb-0:9.0.1-2.fc32.x86_64

/usr/bin/lldb-argdumper
lldb-0:9.0.1-2.fc32.x86_64

/usr/bin/lldb-instr
lldb-0:9.0.1-2.fc32.x86_64

/usr/bin/lldb-mi
lldb-0:9.0.1-2.fc32.x86_64

/usr/bin/lldb-server
lldb-0:9.0.1-2.fc32.x86_64

/usr/bin/lldb-vscode
lldb-0:9.0.1-2.fc32.x86_64

/usr/bin/repl_swift

/usr/bin/swift
python3-swiftclient-0:3.8.1-1.fc32.noarch
swift-lang-0:5.1.3-0.13.20200121gite45437e.fc32.x86_64

I believe the LLVM package would have to also include a Conflict with swift-lang.

I don't think this is going to work (well).

There are several developer-focused tools that depend on system-clang and system-llvm (e.g. gnome-builder, and I think kdevelop as well) - so this would prevent users from using swift and these programs on the same installation ...

I haven't used either of those tools, but I'll bet they are not aware or can deal with Swift code.
My presumption, and it's completely a presumption, is that someone who wants to use Swift will be aware of what tools he or she has available (e.g Vim or Visual Studio Code) to develop in.

True.

Still, what I'm trying to say, is that there's probably a non-trivial overlap between users of these tools and swift-lang (since they're both used by developers).

Login to comment on this ticket.

Metadata