Skip to content

Update the README with Linux package / installer info (RPM/DEB) #37

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.

Sign up for GitHub

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

Merged
merged 5 commits into from
Oct 21, 2021
Merged

Update the README with Linux package / installer info (RPM/DEB) #37

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
5df91b3
Update the README with Linux package / installer info (RPM/DEB)
shahmishal Oct 12, 2021
52ef4ab
Update the Task list to include feedback
shahmishal Oct 12, 2021
68db9c2
Update task list with bugs.swift.org issues
shahmishal Oct 14, 2021
9c7ad47
Adding open questions
shahmishal Oct 18, 2021
314e83c
Add RPM naming convention info to the README
shahmishal Oct 20, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 65 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,71 @@ swift-installer-scripts
└ ...
~~~

## Linux Packages (RPM/Deb)
Copy link
Contributor

@tomerd tomerd Oct 12, 2021 •
edited
Loading

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:

  1. package for development (full toolchain) vs. package for runtime (supporting libraries for swift applications)
  2. location of the swift binaries. eg do we go in /opt or /usr
  3. 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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @futurejones @tachoknight @compnerd @Lukasa @weissi @millenomi

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. 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.

Copy link
Member Author

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 runtime
  • swiftlang-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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. 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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Contributor

@tomerd tomerd Oct 15, 2021 •
edited
Loading

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

Copy link
Contributor

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.

Copy link
Contributor

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.


Currently Swift on Linux is distributed via tarball and Docker, and
we would like to start supporting RPM and Debs officially on swift.org.
The goal is to provide a seamless install process for Swift on Linux by
utilizing the platform’s native package manager (RPM/Deb).


* Step 1. Develop native packages / installers for the distributions
* Step 2. Offer the native packages / installers through swift.org
* Support all officially supported Linux platforms
* Code signed by swift.org certificate
* Repository hosted on swift.org
* Step 3. Offer the native packages / installer through official repositories
for the various platforms
* Work with official repositories to accept package specs
* Deprecate swift.org packages / installer repository
* Step 4. Deprecate swift.org Linux tarballs

### Package Info
Copy link
Contributor

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)

Copy link
Contributor

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 specfile.

Copy link
Member

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.

* Package name: swiftlang
* License: Apache 2.0
* Maintainer: [email protected]
* URL: https://swift.org
* Description:
```
Swift is a general-purpose programming language built using
a modern approach to safety, performance, and software design
patterns.

The goal of the Swift project is to create the best available
language for uses ranging from systems programming, to mobile
and desktop apps, scaling up to cloud services. Most
importantly, Swift is designed to make writing and maintaining
correct programs easier for the developer.
```

## Tasks

### RPM Package Manager (RPM)*

- [ ] SR-### Create RPM spec file
- [ ] SR-### Setup CI job to build the rpm package
- [ ] SR-### Code sign rpm package with swift.org certificate
- [ ] SR-### Host the rpm package on swift.org
- [ ] SR-### Host the rpm repository on swift.org
- [ ] SR-### Verify the rpm package and repository
- [ ] SR-### Update swift.org download / install page
- [ ] SR-### Work with official repositories to accept package specs

*For each platform, we will start with CentOS 8.

### Debian Package (Deb)*

- [ ] SR-### Create Debs control file
- [ ] SR-### Setup CI to build the deb package
- [ ] SR-### Code sign package with swift.org certificate
- [ ] SR-### Host the deb package on swift.org
- [ ] SR-### Host the deb repository on swift.org
- [ ] SR-### Verify the deb package and repository
- [ ] SR-### Update swift.org download / install page
- [ ] SR-### Work with official repositories to accept package specs

*For each platform, we will start with Ubuntu 20.04

## Contributing

Before contributing, please read [CONTRIBUTING.md](CONTRIBUTING.md).
Expand Down