Unable to install gitflow on Fedora 32 with RPM Fusion enabled already

I wanted to install Git Flow tooling for Fedora 32 Workstation. According to the documentation, I just need to:

which says to just run:

sudo dnf install gitflow
keybase                                                10 kB/s | 3.3 kB     00:00
No match for argument: gitflow
Error: Unable to find a match: gitflow

However, when I run this, there is no package available for gitflow. I then looked around and saw some people said it was in the EPEL, which we’re not supposed to enable for Fedora, then others say to enable the RPM Fusion repositories, which those already are. Here is the list of enabled repos:

sudo dnf repolist
[sudo] password for filbot:
repo id                           repo name
code                              Visual Studio Code
fedora                            Fedora 32 - x86_64
fedora-cisco-openh264             Fedora 32 openh264 (From Cisco) - x86_64
fedora-modular                    Fedora Modular 32 - x86_64
google-chrome                     google-chrome
keybase                           keybase
kubernetes                        Kubernetes
rpmfusion-free                    RPM Fusion for Fedora 32 - Free
rpmfusion-free-updates            RPM Fusion for Fedora 32 - Free - Updates
rpmfusion-nonfree                 RPM Fusion for Fedora 32 - Nonfree
rpmfusion-nonfree-updates         RPM Fusion for Fedora 32 - Nonfree - Updates
teams                             teams
updates                           Fedora 32 - x86_64 - Updates
updates-modular                   Fedora Modular 32 - x86_64 - Updates

What would I need to do to install the gitflow package via the dnf package manager? I could install via their script, but I would like it to be managed via dnf.

As you can see, https://src.fedoraproject.org/rpms/gitflow, the package is orphaned. It was last packaged for Fedora 31.

What happened? The package maintainer stopped to maintain it. For which reason? We should search in the devel mailing list, usually the maintainers announce there their intention to stop the maintenance of some package. Then? Nobody else volunteers to take this work for gitflow, hence the package was orphaned and removed from the Fedora repository (for the subsequent releases).


Which mailing lists do you generally look at? My Google-fu brings me to posts from 2015 and RPM Fusion a lot.

So the package is unmaintained and not available. Thank you for the update. I will add that URL you shared earlier to my bookmarks and places to look.


The devel@lists.fedoraproject.org mailing list. However it is a high traffic mailing list and sometimes it is laborious to find old messages. And sometimes it can happen that packagers don’t announce their intent to step down.


When a package is retired from the repositories, the contents of its repository at src.fedoraproject.org/rpms will be replaced by a single file - dead.package - with the reason for retirement. So you should normally be able to look up that reason by looking at the latest commit message (bottom of the package’s page) or contents of the dead.package file. For example, for gitflow the reason is that it had been orphaned for more than 6 weeks, per Fedora policy.

Miro Hrončok regularly sends mails to the devel@ list listing orphaned packages that are in danger of being retired (here’s the latest one), so that they can be picked up by other maintainers & important packages don’t fall through the cracks. Those mails would be the best starting point for finding any discussion regarding the retirement of the package.

The orphaning is unfortunately harder to find, as @alciregi mentioned. The retire-after-6-weeks policy is fairly new, so sometimes packages have been limping along as orphans for a very long time (gitflow’s most recent actual packager commit was 6 years ago, so who knows when it became an orphan or if that was announced to the mailing list …).

Maintaining the myriad packages in Fedora’s repos takes a lot of time & effort, so unfortunately, if nothing depends on a orphaned package, it isn’t very popular and no maintainer has any personal interest in the software, the package will often end up being retired.


Assuming this is the correct upstream, there hasn’t been a commit in 8 years. No code is perfect so I would considered that a dead upstream…


1 Like