The repository has been updated with the new
Update of the package was aborted (ubuntu 21.10) because it tried to overwrite "/usr/lib/python3/dist-packages/six.py" that's also present in package python3-six 1.16.0-2
Python3-six is installed because I have Caffeine installed, it seems.
$ aptitude why python3-six i caffeine Beroende av python3-xlib i A python3-xlib Beroende av python3-six (>= 1.10.0)
@Andreas thanks for the info.
There is a bug in the swift 5.5 build system that includes an old
six.py file for some unknown reason.
This is normally removed when building the debian packages but it got missed in this update.
I have just uploaded an updated package so it should all be fixed now.
Your efforts are most appreciated and I don't want to sound harsh, but I would rather have a list of GPG keys and repo URLs than running a script off the internet with sudo.
@futurejones First off, THANKS for this repository. I can't praise you enough for that, in particular because you're doing what – in my opinion – should be the job of the Swift/Server group.
I don't want to put additional burden on you, but I have some suggestions which would tremendously improve the desolate packaging situation for Swift tools on Linux.
I'm developing a bunch of platform independent command line tools written in Swift.
Since static linking is pretty much broken on Linux, it looks like we have to deal with our tools depending on the Swift libraries for the time being. I'm pondering about doing Debian packaging for my tools and requiring your
swiftlang package. That said, two things come to my mind:
Since a typical command line tool does not need the swift compiler, but only the runtime libraries, would you consider splitting up
swiftlanginto two package? One, say,
libswift5.5.2, for the runtime libraries (which other packages could depend on) and one for the "rest" of the compiler (which, in turn, depends on its runtime library package).
Would it perhaps make sense to work together on a "larger" repository, so to allow
.debhosting for tools that depend on your swift package in the same repository as the language runtime packages?
I think changes like these could make a huge impact on the availability of swift-based tools for Linux, and, in return, attract more people working on such tools.
What do you think?
@mickeyl thanks for the appreciation and feedback.
I have already been working on making a
swift-runtime deb package available.
Rather than split the existing package I have taken the same approach and naming convention as the
swift-docker there is the main
swift image and a
swift-slim image that just contains the
I have added
swiftlang-slim (swift-runtime) for 5.5.2 packages to the
main repository for the following distributions -
- Ubuntu bionic, focal and hirsute
- Debian buster and bullseye
These are just for
arm64 at the moment. I will add slim packages for
amd64 as well soon.
They can be installed with
sudo apt install swiftlang-slim or added to any swift application deb package as a dependency.
I think it would be a great idea to extend the repository to include all types of swift-based tools for Linux. It would be fairly straight forward to add a
dev-tools section to the repository and get started.
Let me know when you have something you want to upload and test.