Update the README with Linux package / installer info (RPM/DEB) #37
Conversation
|
cc: @tomerd @tachoknight @futurejones @compnerd @discogestalt I am planning on creating the bugs.swift.org tickets to track the work after we review the README. |
| * Deprecate swift.org packages / installer repository | ||
| * Step 4. Deprecate swift.org Linux tarballs | ||
|
|
||
| ### Package Info |
There was a problem hiding this comment.
@futurejones @tachoknight @compnerd please review and see if you have any feedback on the suggested metadata here (this is a draft)
There was a problem hiding this comment.
In the Debian section Create Debs spec file should be changed to Create Debs control file as deb packages don't use a specfile.
There was a problem hiding this comment.
I think that we should consider the renaming policy for Debian: https://wiki.debian.org/RenamingPackages. It may still be possible to use swift as the package name. While it is common for some languages (e.g. go) to use the lang suffix, it generally goes by golang and rather than go. Rust does something similar: rust is the package name and provides an uber package (rust-all) for installing all the pieces together.
| @@ -25,6 +25,71 @@ swift-installer-scripts | |||
| └ ... | |||
| ~~~ | |||
|
|
|||
| ## Linux Packages (RPM/Deb) | |||
There was a problem hiding this comment.
few other things we need to agree on and document are:
- package for development (full toolchain) vs. package for runtime (supporting libraries for swift applications)
- location of the swift binaries. eg do we go in /opt or /usr
- how would we version the packages, especially in light of lack of stable abi on linux? is minor version and being careful with patch versions enough, or should we issue a package per patch version?
There was a problem hiding this comment.
There was a problem hiding this comment.
- location of the swift binaries. eg do we go in /opt or /usr
With deb packages I have found using the /usr directory works best for addressing conflicts with existing native installs such as clang, llvm, lldb , libicu etc.
It also makes it quick and simple to create the deb packages from the existing swift.tar.gz files as they are already using /usr.
There was a problem hiding this comment.
package for development (full toolchain) vs. package for runtime (supporting libraries for swift applications)
We should have two packages:
swiftlang- contains both the compiler and runtimeswiftlang-runtime- contains only runtime
However, we should focus on swiftlang first and work on swiftlang-runtime after we have setup swiftlang.
how would we version the packages, especially in light of lack of stable abi on linux? is minor version and being careful with patch versions enough, or should we issue a package per patch version?
We should use the full version including the patch version until we are ABI stable on Linux platform.
There was a problem hiding this comment.
- how would we version the packages
With deb packages there are 2 parts to the package versioning, version and iteration.
The version number is the version of the package contents and should be exactly the same as the swift-release number e.g. 5.4.3, 5.5 etc. A new package needs to be built and released for every release, major, minor and patch level.
The iteration number is the version of actual package.
e.g. 01-ubuntu-focal would indicate this is the first release of the ubuntu-focal package.
The full package name would be [name][version][iteration] e.g. swiftlang_5.4.3-01-ubuntu-focal.
Problems with stable abi and which version is installed needs to be handled at the repository level.
The repository needs to be flexible enough to allows users to choose which version of Swift is installed and how that will be updated when running sudo apt update && upgrade.
There was a problem hiding this comment.
I believe that /opt is the right place for the swift packages to install to for the forseeable future. Until the llvm-project conflict is resolved, we have a conflict with a large number of packages. By placing the package into /opt, we can have co-installation of the packages and the user can simply alter the path to get either the swift packages or the system packages for clang and the rest of the binary tools from llvm. I don't think that the llvm-project fork is something that will be resolved in a month or so, so, for that duration we should prefer /opt as if Swift was a binary package that was shipped by a vendor. Once the llvm-project fork issue has been resolved, we could easily work to split up the toolchain into separate clang/llvm/lld/lldb packages and provide newer versions of the package as dependencies for Swift. At that time, we would have a natural motivation and point for transitioning from /opt to /usr.
There was a problem hiding this comment.
Summary from the meeting we had today, we will need to have a follow up meeting.
Attendees: @tomerd @tachoknight @compnerd @shahmishal
Location:
Option 1: Diverge the install location between platform to best fit the platform requirements.
- symlink the toolchain into /usr/ to avoid conflicting with llvm.org binaries.
Option 2: Install in /usr and rename llvm-project binaries (example: swift-lldb/lldb-swift ...)
Option 3: Install in /opt however this will not for work fedora, and we will still have issue with llvm-project binaries.
We did not get to the discussion about multiple version or multiple packages (runtime vs full package).
@tomerd @tachoknight @compnerd feel free to add anything I missed.
There was a problem hiding this comment.
Option 3: Install in /opt however this will not for work fedora, and we will still have issue with llvm-project binaries.
I dont think the latter part of the sentence is true, afaiu from @tachoknight its more that in fedora you are not allowed to use /opt
There was a problem hiding this comment.
I dont think the latter part of the sentence is true, afaiu from @tachoknight its more that in fedora you are not allowed to use /opt
Correct, per Fedora's Packaging Guidelines.
There was a problem hiding this comment.
I would prefer Option 1 — Until we finally manage to separate out all the dependencies.
For multiple versions and packages,
swiftlang
-> swiftlang5
-> swiftlang5.6
-> swiftlang5.6-runtime
-> swiftlang5.6-...
-> ...
may be a possible naming convention. This will allow user to keep any x.y releases of Swift, or to keep up with the latest toolchain.
|
Added open questions section and RPM naming convention to the README. Should we merge this and continue the discussion about location and other open question in forums.swift.org or in this PR? thoughts? |
|
I'd suggest the forums; it's pretty easy to get lost in GitHub's PR interface, and the discussion may span multiple PRs. |
|
-1 on move discussions to the swift forums. |
No description provided.