You need Slack, but the download page is confusing
You joined a new team and the workflow runs entirely through Slack. You open the official download page, grab the Fedora RPM link, and paste it into the terminal. The install fails with a dependency error, or worse, it succeeds but the package refuses to update because the version metadata is hardcoded to a Fedora release that no longer exists. You need the application working, but you also need your system to stay clean and upgradeable without manual intervention.
What the RPM and repository actually do
Slack does not ship in the default Fedora repositories. The Fedora project focuses on free and open-source software for the base system. Proprietary applications are available through third-party channels. The official Slack download page offers an RPM package. That package works, but the download link contains a version number tied to a specific Fedora release. If you install slack-4.36.140-1.fc39.x86_64.rpm on Fedora 40, the package manager might reject it, or it might install and then refuse to update because the metadata claims it belongs to an older release.
The direct RPM approach treats Slack as a static file. The repository approach treats Slack as a managed package. Managed packages update when you run your normal system maintenance. Static files drift and cause conflicts.
When you pass a URL to dnf install, the package manager downloads the RPM to a temporary directory, reads the metadata, checks dependencies against your enabled repositories, and queues the transaction. It does not register the URL as a source. This means the next time you run dnf upgrade, dnf has no idea where Slack came from. It sees the package but cannot find updates. The repository method solves this by installing a configuration file that tells dnf where to look for Slack indefinitely.
The repository configuration lives in /etc/yum.repos.d/. Files in this directory define package sources. The Slack repository package installs a .repo file that points to PackageCloud, the hosting service Slack uses for distribution. The file uses variables like $releasever to automatically match your Fedora version. This ensures the correct packages are fetched without manual URL editing.
Install Slack using the repository method
The repository method is the standard approach for long-term use. It integrates Slack into your package management workflow. Run the commands below to add the source and install the application.
First, check your Fedora release version. You need this number to verify compatibility if you ever need to troubleshoot.
rpm -E %fedora
# WHY: Returns the numeric release ID (e.g., 40). This matches the fcXX suffix in package names and helps diagnose version mismatches.
Install the repository package. This package contains only the configuration files needed to talk to the Slack package server. It does not install Slack itself.
sudo dnf install -y https://downloads.slack-edge.com/linux_packages/slack-repo-1.0-1.noarch.rpm
# WHY: Installs the repository definition into /etc/yum.repos.d/. This enables dnf to find and update Slack automatically in the future.
Install Slack from the repository you just added. The package manager pulls the latest version compatible with your system.
sudo dnf install -y slack
# WHY: Downloads and installs the Slack binary and dependencies from the official repository. Future dnf upgrade commands will include Slack.
Verify the repository file was created correctly. This confirms the source is registered.
[slack]
name=Slack
baseurl=https://packagecloud.io/slacktechnologies/slack/fedora/$releasever/$basearch
gpgcheck=1
gpgkey=https://packagecloud.io/slacktechnologies/slack/gpgkey
enabled=1
# WHY: This file lives in /etc/yum.repos.d/. The $releasever variable ensures dnf requests packages for your exact Fedora version. gpgcheck=1 enforces signature verification.
Run the repo install first. A direct RPM download creates technical debt you will pay later.
Verify the installation
Confirm the package is installed and the metadata is registered. This step ensures the binary is present and the package manager knows about it.
rpm -q --changelog slack | head -n 5
# WHY: Displays the installed version and recent changelog entries. If this returns nothing, the package is not installed or the database is corrupted.
Launch the application to ensure it starts correctly. You can run it from the terminal to see any startup errors.
slack &
# WHY: Starts Slack in the background. Running from the terminal allows you to read any error output if the GUI fails to appear.
Check the version string. If rpm -q slack returns the package name, the binary is present and the metadata is registered.
Common pitfalls and error messages
Direct RPM links often cause version mismatch errors. The error looks like this:
Error: Transaction test error:
package slack-4.36.140-1.fc39.x86_64 conflicts with slack provided by slack-4.37.100-1.fc40.x86_64
This error appears when you try to install a direct RPM for a different Fedora release than the one running on your system. The package metadata contains a conflict directive to prevent mixing versions. The repository method avoids this because the .repo file uses $releasever to fetch the correct version automatically.
GPG key errors can occur if the repository configuration is missing the key URL. The error looks like this:
Public key for slack.rpm is not installed
The official repository package includes the GPG key configuration. If you see this error, the repository package did not install correctly. Re-run the repository install command. Do not disable GPG checking. Signature verification protects against tampered packages.
Direct RPM installations drift over time. If you install via direct link, dnf upgrade will never update Slack. You must manually download new RPMs and install them. This leads to outdated software and potential security issues. The repository method keeps Slack current with a single command.
Read the error code. A version mismatch means you grabbed the wrong RPM. A GPG error means the key is missing. Never ignore the error text.
Choose the right installation method
Select the approach that matches your update strategy and system constraints.
Use the official RPM repository when you prefer native integration and want to manage Slack alongside your system packages using dnf.
Use the direct RPM link when you are on a restricted network that blocks repository metadata downloads but allows single file transfers.
Use the Flatpak version when you want sandboxed isolation and automatic updates independent of your system package manager.
Use the web client when you need to access Slack immediately without installing any software.
Match the method to your workflow. If you manage packages with dnf, use the repo. If you isolate apps, use Flatpak.