Why does swift not support CentOS platform?
2 Likes
Who can answer my question? 
Who can answer my question?
In this case, I think you can answer your question (-: Try searching the forums for CentOS. There’s been a bunch of threads about this, including some quite recent ones.
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple
1 Like
No answer🙂
What do you mean by “actually use”? Ubuntu has a large usage share among server linuxes, and therefore still seems like a reasonable target. Note that the stated goal of swift on Linux is server-side swift.
If someone would commit to setting up and maintaining CI infrastructure for non-ubuntus, I’m sure the issues that came up would be addressed. Has anyone done so? Does it have to be apple? Seems like they don’t think so.
I have thought about how it might be nice for there to be community-driven CI infrastructure for various Linux distros, but there are two main hurdles involved that I can think of right now.
The first challenge is that it can be tricky to get Swift building on Linux distros besides Ubuntu without an in-depth knowledge of how the Swift build system. That means that this project is best-suited for someone who has a good deal of experience with the Swift project.
The second challenge is "credibility," I suppose. If you do manage to get a CI set up for various Linux distros, some may be hesitant to actually use something that isn't "Apple-sanctioned."
To ensure the OPs know about what exists:
https://swift.org/blog/swift-community-hosted-ci/
In short, there once were Fedora and Debian nodes. They have not succeeded for months.
To play devil's advocate, while Ubuntu is a very common distribution both on desktop and server, it is by no means the only popular one. Especially, on servers, Debian, RHEL and CentOS are very popular, and the fact that they are not natively supported means that Swift on Linux is not really where it should be in order to be widely adopted.
Even on Ubuntu, Swift is distributed as a tarball instead of being packaged as a .deb (or snap package, if that's more acceptable), which isn't really how Linux users like to install software (it also means that updating is more cumbersome).
Furthermore, recent installations of Swift break the system for other packages, which means that Swift is not really behaving like a good citizen on Linux.
All to say that, while the tone of this thread (and similar ones) might not be very productive, the frustration with trying to use Swift on Linux is very real.
4 Likes
To your first challenge: I completely disagree. This is something suited for the Linux package maintainers. There are too many differences between the Linux distributions. Some distributions (e.g. exherbo, nixOS, GoboLinux) use a custom layout. Other distributions package parts of other languages differently (e.g. Ubuntu). There are distribution specific guidelines on how to write package rules. In general, ports maintainers are well versed in building/writing software. In fact, speaking as a ports maintainer, I would rather that the project not try to attempt to write the package rules unless they are also part of the Linux distribution. In my experience, they do not often keep up with changes in the Linux distribution well enough and the package definition still gets widely adopted leading to time wasting bugs trying to understand why things don't work for some people. IMO, this firmly in the realm of the Linux distribution(s).
I think that anyone with an affiliated email address for the distribution would be credible enough to request that we add a donated host to the community CI (note that this does not preclude someone from requesting that we add an unofficial CI assuming that they can show that they have the right to permit the project to use the builder). There is a licensing step of course to permit the use of the resource, but again, I imagine that anyone acting on behalf of the distribution would be able to get that resolved.
While I think that it would be great to support additional linux distributions, I don't think that is something which should be deemed to be the responsibility of the Swift project. Even the LLVM/clang projects do not support all Linux distributions. They only support Ubuntu. Minor exaggeration - I know they do support exherbo as I added that support as a representative of exherbo and some other Linux distributions setup their paths similarly enough where it may happen to work as clang/LLVM are far less complicated.
Given that clang/LLVM, which are required dependencies, only support Ubuntu, I think that the responsible thing for the Swift project is to only support Ubuntu until clang/LLVM officially support other distributions as well. But even in such an eventuality, it would require the Linux distributions to support that work for it to yield a package that integrates well.
From my experiences as a ports maintainer for Gentoo and exherbo, I think that the only way to really get the optimal experience is if the packaging step is done in the official distribution package repository rather than in the project. That would allow installation with the system package manager and tracking of updates properly.
Beyond requesting that your Linux distribution of choice packages Swift (which I highly recommend), as a stop gap measure, sending pull requests to address the Linux distribution specific behaviour (which will be required when the distribution attempts to package Swift anyways) is welcome. There have been packages to address issues with building on exherbo which I did add since the distribution is not Ubuntu and is different enough to require additional changes. I would happily review such changes.
3 Likes
@yxckjhasdkjh If you are interested in helping package stuff up as .debs for swift, there is a whole project from LLVM that would be a good starting point/reference/place to ask for guidance:
*To be clear, when I said from LLVM, I mean it is not actually affiliated with LLVM directly but I have seen the committers in the llvm-irc/etc. The two parts you want to look at are "Technical Aspects" at the bottom of the page and also:
which is where all of the tools are.