It seems to me the ngircd package has a problem on Fedora 31:
# dnf repolist
repo id repo name
fedora Fedora 31 - x86_64
fedora-modular Fedora Modular 31 - x86_64
updates Fedora 31 - x86_64 - Updates
updates-modular Fedora Modular 31 - x86_64 - Updates
# dnf --refresh install ngircd
Fedora Modular 31 - x86_64 31 kB/s | 23 kB 00:00
Fedora Modular 31 - x86_64 - Updates 28 kB/s | 21 kB 00:00
Fedora 31 - x86_64 - Updates 29 kB/s | 22 kB 00:00
Fedora 31 - x86_64 44 kB/s | 23 kB 00:00
Problem: conflicting requests
- nothing provides libident.so.0()(64bit) needed by ngircd-25-3.fc31.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
Whether the problem is libident having been unintentionally removed from the repos or ngircd being built without ident support and the RPM not reflecting that or a misconfiguration of my system I have no idea, so I’m asking here: Is there anybody who can tell me which one it is?
Here you have two option (I suggest to you do both):
1.- Report a Bug against this package follow this procedure: How to file a bug :: Fedora Docs
2.- Install the dependency from fedora 28: libident-0.32-17.fc28 | Build Info | koji
and try again…
- 28 is the latest build State complete
- 29 State failed
- 30 State failed
- 31 State failed
This is happening with a few packages of Fedora 31, for example with eclipse-m2-core or hibernate-core. I filled a bug in Red Hat Bugzilla about the impossibility to install hibernate-core (1770537 – Hibernate can't be installed) and look at their answer:
As no package depends on hibernate and class mvn(org.hibernate.common:hibernate-commons-annotations) is already orphaned, we are aiming to orphan also hibernate package. If you have a reason, that hibernate should stay in fedora, let us know please.
Funny thing if you take into account that Hibernate is a framework owned by Red Hat and is integrated in their JBoss/Wildfly application server.
I just hope it’s not the start of a trend. I’ve used RH/Fedora for many years, partly because its package repo is huge, and it has little bit rot and at the same time pretty fresh packages. That’s really quite rare. “Break, wait, remove” is not exactly the ideal way to EOL a package.