Perhaps I’m missing something obvious, but I’m puzzled by the following
I have an up-to-date Webmin 2.013 installed on an up-to-date Rocky Linux 9.1 system. (The Linux system was first installed very recently: in mid-January.) I installed Webmin and keep it up-to-date via the official Webmin repository. So far, so good
I have a small mail server on the Rocky Linux 9.1 system, and just today, I wanted to install SpamAssassin, which is in the official Rocky Linux repository. The problem is that the command dnf install SpamAssassin proposes to install 91 new packages (fine) but also to downgrade one package, namely, Webmin, to version 1.790 of Webmin, which makes absolutely no sense to me!
Naturally, I said no to the proposed installation of SpamAssassin, because I certainly don’t want to downgrade Webmin to version 1.790 for the sake of installing SpamAssassin!
Can anyone replicate this issue? Have I missed something or done something wrong?
Where are you getting the SpamAssassin package from and why does it depend on an ancient version of Webmin? (I assume that’s what’s happening, but I’m guessing. We don’t have enough information to really troubleshoot this.)
Check your yum repo configuration. Something weird is happening there, I assume.
It’s also possible the SpamAssassin version you’re trying to install depends on some Perl package that conflicts with some Perl package we depend on, and it is possible we didn’t specify a version in the past, but do specify a version now and the version SpamAssassin wants is not the one we depend on. I don’t know. Still just guessing wildly. But, I think it’s almost certain you have some third party repos configured, and it has some version of SpamAssassin that is weird, because we haven’t had any trouble installing the Rocky 9 SpamAssassin package alongside Webmin in the Virtualmin installer (same Webmin package, just re-signed with the Virtualmin key).
As I said above, this is a rather fresh installation. The only additional repos that I’ve activated are crb, epel, and Webmin. Nothing fancy or risky, I think
SpamAssassin (version 3.4.6) is included in the standard repo appstream
I also think that must be a Perl package conflict of some kind, but I have no idea what it’s due to exactly
For what it’s worth, here’s a comparison of the dependencies of (the installed) Webmin 2.013 with the dependencies of Webmin 1.790, which is the proposed (massive) downgrade
I have no idea. I just did a test install without issue, with every variable matching what you’ve told me you’ve done. Fresh Rocky 9.1, installed Webmin from webmin.com repos, installed spamassassin.
I understand. I appreciate your efforts. And I agree that it does look like I’ve simply missed something (or that I’m insane!)
Let me just add another puzzling detail though
If I do dnf install spamassassin, I get a list of 91 packages to install and 1 package to downgrade, namely, Webmin, from version 2.013 to version 1.790, which is an absurd suggestion, as I said above
Some minutes ago, it occurred to me to try to temporarily disable the Webmin repo to see what would happen
If I do dnf --disablerepo=Webmin install spamassassin, I get a list of 92 packages to install and 0 to downgrade!
In the latter case, the additional package to be installed is perl-JSON
I have no idea what to make of this: so perl-JSON is installed if I disable the Webmin repo but not if I enable the Webmin repo? And if I enable the Webmin repo, then perl-JSON is not installed but Webmin must be downgraded?
This makes no sense at all to me!
@Joe : if I may ask, is perl-JSON installed on your test system?
In sum, it appears that I can install SpamAssassin by temporarily disabling the Webmin repo, but I may wait until tomorrow to try. But I’m afraid that I still don’t understand this
We ship a version of the JSON module bundled in Webmin, but rpm should not consider our version satisfying that dependency for anybody else (it’s local to Webmin). rpmbuild has some macros that automatically detect provided Perl libs, but I don’t think we’re running it in a way that it would do that for our package.
I don’t understand why it’d try to downgrade, though, even if our old package did have a bug where it pretends to provide a library it really doesn’t.
Let me add that if I do dnf install perl-JSON, it appears that I could install perl-JSON without needing to downgrade Webmin
Which is somehow consistent with what I observed above, because although perl-JSON isn’t installed if the Webmin repo is enabled and it is installed if the Webmin repo is disabled, its installation doesn’t require the presently installed Webmin 2.013 to be deleted (nor is there a conflict explicitly signaled between perl-JSON and Webmin 2.013)
Okay, I have a solution. I don’t understand why this solution works, but by all signs, it works
I won’t repeat everything that I said above, but recall that the command dnf install spamassassin wanted to install 91 packages and to downgrade Webmin from version 2.013 to version 1.790, which was absurd
In contrast, the command dnf --disablerepo=Webmin install spamassassin wanted to install 92 packages, the additional package being perl-JSON, but would leave Webmin 2.013 alone
The solution is the following (the Webmin repo is enabled, as usual):
First: dnf install perl-JSON (which just installs perl-JSON and leaves Webmin 2.013 alone)
Then: dnf install spamassassin (which installs the original 91 packages and now leaves Webmin 2.013 alone)
I still don’t understand the logic of this, but it’s as though SpamAssassin wanted to install perl-JSON, but the presence of Webmin 2.013 and the enabled Webmin repo prevented it, but if perl-JSON is already installed, then SpamAssassin is happy and doesn’t care about the presence of Webmin 2.013 or the enabled Webmin repo
The confusing thing is I didn’t have to do any of that. I was able to install webmin, and then install spamassassin, with no drama. I didn’t need to disable any repos, it all just worked.
As far as I can tell, the third-party repos crb or epel didn’t played any interfering role here, because I have just a handful of packages installed from them, and they don’t concern Webmin or SpamAssassin
In mid-January, I originally installed Webmin 2.0.12, which I later updated, so this would be a tiny difference between your and my attempts, but this shouldn’t matter
Although I’m baffled by this behavior, at least there’s an easy solution