Installing helm on Fedora 37

Hi everyone; I hope you all are having a wonderful day :wave:

This time, I’d like to learn why there are some applications packaged for previous Fedora versions shipped in the latest Fedora release repositories, i.e.:

$ dnf info helm
Last metadata expiration check: 0:01:00 ago on Wed Jan 11 08:52:15 2023.
Installed Packages
Name         : helm
Version      : 3.5.4
Release      : 2.fc35
Architecture : x86_64
Size         : 46 M
Source       : golang-helm-3-3.5.4-2.fc35.src.rpm
Repository   : @System
From repo    : fedora
Summary      : The Kubernetes Package Manager
URL          :
License      : ASL 2.0
Description  : 
             : Helm is a tool for managing Charts. Charts are packages of pre-configured
             : Kubernetes resources.
             : Use Helm to:
             : - Find and use popular software packaged as Helm Charts to run in Kubernetes
             : - Share your own applications as Helm Charts
             : - Create reproducible builds of your Kubernetes applications
             : - Intelligently manage your Kubernetes manifest files
             : - Manage releases of Helm packages

I couldn´t find any relevant documentation. I’d be grateful if anyone could point me in the right direction.

Many thanks!

Not familiar with the package but looking at the build system, it seems that after f35, the package build failed, see golang-helm-3 | Package Info | koji and Overview - rpms/golang-helm-3 -
So, the latest sucessful build is distributed… I wouldn’t worry, since the version is identical for all recent releases.

It’s not uncommon to have packages from f35 installed on f36 or f37, check with dnf -C list |grep fc35 |wc -l

edit: Looking at src.fp.o for a second time, the package has been orphaned (see also 2142198 – F37FailsToInstall: golang-helm-3-devel) and will be removed from Fedora if nobody takes care of the issue.


I use helm regularly and unfortunately use the installer script, which does work on Fedora. I suggest removing it from dnf before installing it via script as they will likely conflict if you don’t. It’s an unfortunate reality that this is how most Kubernetes type tools get shipped.

1 Like

Thank you so much for your explanation, helps me understand how this works.

As a side note, I’ll take a look at the package and see if I can step in to lend a hand.


Hi Scott,

I feel your pain :sweat_smile:

I was looking to build a custom container for some GitLab pipelines at work, and I was looking into the official Podman image, trying to understand if it could fit my needs.

Sadly enough, the resulting image turned out to be a fat mess full of bloat (even if removing DNF’s cache and avoiding installing any weak dependencies), so I based my image on Alpine Linux.

Luckily Alpine ships the latest Helm version, so I could get rid of the Helm installation script.

We are investigating different avenues for implementing a proper GitOps workflow tho, so we should be able to let Helm go in a few months when we re-engineer our deployment pipelines :pray:

1 Like

Nothing wrong with that. Alpine Linux is highly useful as a container image base. Glad you found a way forward!