-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the Debian
section Create Debs spec file
should be changed to Create Debs control file
as deb packages don't use a spec
file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.