Missing python-zmq dependencies while bootstraping CentOS 7 Salt client

[phibid]

Using Uyuni release 2020.03

While trying to bootstrap a CentOS 7 Salt client, I have the following error:

---> Package python-zmq.x86_64 0:14.5.0-3.7.uyuni will be installed
--> Processing Dependency: libzmq.so.4()(64bit) for package: python-zmq-14.5.0-3.7.uyuni.x86_64
--> Finished Dependency Resolution
Error: Package: python-zmq-14.5.0-3.7.uyuni.x86_64 (susemanager:bootstrap)
           Requires: libzmq.so.4()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
package salt is not installed
ERROR: Failed to install all missing packages.

The zeromq package picked up during the CentOS 7 bootstrap channel creation is the one from EPEL and not the one from Uyuni Client repo, which breaks afterwards the dependencies during the bootstrap process.

On the Uyuni server, searching for zeromq package, I have the following results:

zeromq-4.1.6-11.11.uyuni.x86_64	Uyuni Client Tools for CentOS 8 (x86_64)
zeromq-4.0.5-1.7.uyuni.x86_64	Uyuni Client Tools for CentOS 7 (x86_64)
zeromq-4.3.2-1.el8.x86_64	EPEL 8 for CentOS 8 (x86_64)
zeromq-4.1.4-6.el7.x86_64	EPEL 7 for CentOS 7 (x86_64)

Downloading/installing by hand zeromq-4.0 rpm from the Uyuni Client repo solve the dependency issue. The bootstrap creation should only pick up the packages from this repository.

Not tested yet, but I guess that the behaviour is the same bootstrapping a CentOS 8 Salt client, as I can see that zeromq-4.3.2 is present in the bootstrap channel.

Not sure if this issue has a relation with #1275 ?

[juliogonzalez]

Yes, the problem is that the bootstrap repository generator picks the most recent version available on the channels assigned to that OS. So in this case it included zeromq-4.1.4-6.el7

So it's not really related to #1275, I'd say. Here the problem seems to be zeromq itself.

What does zeromq-4.1.4-6.el7.x86_64 provides? Maybe `libzmq.so.5' ? That could explain the failure.

For now the only solution I can see is creating the bootstrap repository before adding EPEL, but of course if then the repository is recreated this will happen again.

Not to mention that I am not sure what yum is going to tell if you try to update (should tell you it can't update some packages, or maybe it will ask you to drop python-zmq and salt).

@brejoc any suggestions?

[phibid]

Yes this is what I have done, and this is indeed working. EPEL channel removal before the bootstrap repository, solve the initial issue.

However only partially, because the conflicts are still there. If I add EPEL channel afterwards on the registered client, I still run into a package conflict issue. Result of a "yum update"

Error: 
 Problem: package python3-salt-2019.2.3-17.2.uyuni.x86_64 conflicts with python3-tornado >= 5 provided by python3-tornado-6.0.2-1.el8.x86_64
  - cannot install the best update candidate for package python3-tornado-4.2.1-1.12.uyuni.x86_64
  - cannot install the best update candidate for package python3-salt-2019.2.3-17.2.uyuni.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

[paususe]

I'm going to close this one, since adding an unfiltered EPEL is a known issue as explained in the release notes.