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.
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).
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.
Well, what I mean is that in general, 8 years is a long time without any commits. If this project was C++ based, that would be like 4 major releases? We technically incorrectly call it “bit rot”, it’s not that the code rotts, but as the compiler gets smarter about finding errors in code it can make it very difficult to maintain.
