Webmin 2.013, Rocky Linux 9.1, SpamAssassin

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?

You’ve almost certainly 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).

1 Like

Thank for your quick reaction

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

Dependencies of (the installed) Webmin 2.013:

# dnf repoquery --requires webmin-2.013
/bin/rm
/bin/sh
/usr/bin/perl
openssl
perl(Data::Dumper)
perl(Digest::MD5)
perl(Digest::SHA)
perl(Encode::Detect)
perl(Net::SSLeay)
perl(Time::Local)
perl(lib)
perl(open)
tar
unzip

Dependencies of Webmin 1.790:

# dnf repoquery --requires webmin-1.790
/bin/rm
/bin/sh
/usr/bin/perl
openssl
perl(Net::SSLeay)

But I’m not sure what to conclude from this … :neutral_face:

For completeness, I’ll add the dependencies of SpamAssassin 3.4.6, which is the current version in the repo appstream:

# dnf repoquery --requires spamassassin-3.4.6
/bin/sh
/usr/bin/bash
/usr/bin/perl
/usr/bin/sh
diffutils
gnupg2
libc.so.6(GLIBC_2.34)(64bit)
libssl.so.3()(64bit)
libssl.so.3(OPENSSL_3.0.0)(64bit)
perl(:MODULE_COMPAT_5.32.1)
perl(:VERSION) >= 5.6.0
perl(:VERSION) >= 5.8.0
perl(:VERSION) >= 5.8.1
perl(AnyDBM_File)
perl(Archive::Tar)
perl(Archive::Tar) >= 1.23
perl(BSD::Resource)
perl(Carp)
perl(Config)
perl(Cwd)
perl(DB_File)
perl(Data::Dumper)
perl(Digest::MD5)
perl(Digest::SHA)
perl(Encode::Detect)
perl(Errno)
perl(Exporter)
perl(ExtUtils::MakeMaker)
perl(Fcntl)
perl(File::Basename)
perl(File::Copy)
perl(File::Path)
perl(File::Spec) >= 0.8
perl(Getopt::Long)
perl(HTML::Parser) >= 3.43
perl(HTTP::Date)
perl(IO::File)
perl(IO::Handle)
perl(IO::Pipe)
perl(IO::Socket)
perl(IO::Socket::INET6)
perl(IO::Socket::SSL)
perl(IO::Socket::UNIX)
perl(IO::Zlib) >= 1.04
perl(LWP::UserAgent)
perl(List::Util)
perl(MIME::QuotedPrint)
perl(Mail::DKIM)
perl(Mail::SPF)
perl(Mail::SpamAssassin)
perl(Net::CIDR::Lite)
perl(Net::DNS)
perl(NetAddr::IP) >= 4.000
perl(POSIX)
perl(Pod::Usage)
perl(Socket)
perl(Sys::Hostname)
perl(Sys::Syslog)
perl(Time::HiRes)
perl(Time::Local)
perl(XSLoader)
perl(base)
perl(constant)
perl(lib)
perl(re)
perl(strict)
perl(vars)
perl(version) >= 0.77
perl(warnings)
perl-HTML-Parser >= 3.43
procmail
rtld(GNU_HASH)
systemd-sysv
systemd-units

Unfortunately, I can’t discern where the package conflict would be

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.

[root@rocky-9-webmin-test ~]# cat /etc/redhat-release 
Rocky Linux release 9.1 (Blue Onyx)
[root@rocky-9-webmin-test ~]# rpm -q webmin
webmin-2.013-1.noarch
[root@rocky-9-webmin-test ~]# rpm -q spamassassin
spamassassin-3.4.6-5.el9.x86_64

No errors, no dependency issues.

Calling this done, as it can’t be reproduced.

1 Like

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 :neutral_face:

What does this give you?

dnf provides perl-JSON

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.

It gives the appstream version (as it should, so this is good news):

dnf provides perl-JSON
Last metadata expiration check: 0:43:38 ago on Fri Feb  3 22:33:52 2023.
perl-JSON-4.03-5.el9.noarch : Parse and convert to JSON (JavaScript Object
                            : Notation)
Repo        : appstream
Matched from:
Provide    : perl-JSON = 4.03-5.el9

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)

So it’s still a puzzle to me :neutral_face:

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)

:slightly_smiling_face:

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

Go figure :upside_down_face:

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.

I believe you, of course

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

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.