New Swift Package Repository for Ubuntu/Debian Linux Distributions

Swift 5.5.1 Release

The repository has been updated with the new swift-5.5.1-RELEASE

3 Likes

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.

:ok_hand: Works great

Swift 5.5.2 Release

The repository has been updated with the new swift-5.5.2-RELEASE

7 Likes

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.

1 Like

@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:

  1. Since a typical command line tool does not need the swift compiler, but only the runtime libraries, would you consider splitting up swiftlang into two package? One, say, swift-runtime or, e.g., 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).

  2. Would it perhaps make sense to work together on a "larger" repository, so to allow .deb hosting 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?

1 Like

@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 images.
With swift-docker there is the main swift image and a swift-slim image that just contains the swift-runtime.

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.

3 Likes
Terms of Service

Privacy Policy

Cookie Policy