3 thoughts on - Mock Gimmicks – Experts?

• Rather than passing in both SRPMS .. I would try with just one at a time.

  You are first trying to build mpfr and after that, you are trying to build libmpc.

  If I am correct, the newer version of libmpc is required for mpfr. So, first try building libmpc .. and look at what is necessary to build that. Once you have that built, put it in your local repo and rebuild tehmetadata and thentry to build mpfr by itself.

  All ‘–chain’ does is retry all failed builds if something actually builds.

  As to why the older version of libmpc or mpfr is trying to load .. look at your root.log and it will tell you.

• -> $ mock -r CentOS-stream-8-x86_64 –rootdir=~/mock
  –resultdir=/00.STORAGE/1/var/www/repos/results/”{{root}}”/libmpc libmpc-1.2.1-4.el9.src.rpm

  …

  Package gcc-8.5.0-10.el8.x86_64 is already installed. Package make-1:4.2.1-11.el8.x86_64 is already installed. No matching package to install: ‘mpfr-devel >= 4.1.0’
  Not all dependencies satisfied

  ‘–chain’ I believed was some way to “loop” and if one pkg might depend on another it will (with perhaps of addition of ‘–continue’) that would be better alternative to “solve” those dependencies, anyway.

  Having ‘mpfr’ ver. 4.x built and in repo, following fails the same way:

  -> $ mock -r CentOS-stream-8-x86_64 –rootdir=~/mock
  –resultdir=/00.STORAGE/1/var/www/repos/results/”{{root}}”/libmpc libmpc-1.2.1-4.el9.src.rpm
  –addrepo=http://10.3.1.100/CentOS-stream-8-x86_64
  …

  CentOS Stream 8 – PowerTools 113 kB/s | 4.4 kB     00:00
  Error:
   Problem: cannot install the best update candidate for package libmpc-1.1.0-9.1.el8.x86_64
    – problem with installed package libmpc-1.1.0-9.1.el8.x86_64
    – package libmpc-1.1.0-9.1.el8.x86_64 requires libmpfr.so.4()(64bit), but none of the providers can be installed
    – cannot install the best update candidate for package mpfr-3.1.6-1.el8.x86_64
    – cannot install both mpfr-4.1.0-7.el8.x86_64 and mpfr-3.1.6-1.el8.x86_64
    – cannot install both mpfr-3.1.6-1.el8.x86_64 and mpfr-4.1.0-7.el8.x86_64
  (try to add ‘–skip-broken’ to skip uninstallable packages or ‘–nobest’
  to use not only best candidate packages)

  ‘root.log’ does not reveal anything, certainly not an explanation or… I’ve gone blind.

  My guess – because that would be such a “test” case where ‘mock’ fails to tell, to explain what/how so I must only guess – is that something else down the chain of dependencies, depends on those “older” versions of ‘mpfr’ and/or ‘libmpc’, but..

  if that theorem is true then, again, how to…

  I also fiddled with ‘best=’ but to no avail.

  many thanks, L.

• https://koji.mbox.CentOS.org/pkgs/packages/libmpc/1.1.0/9.1.el8/data/logs/aarch64/root.log

  libmpc.aarch64 is installed in the ‘minimal’ buildroot for all packages built in mock. So you will have to build a newer first. (The minimum build root contains the files starting with:

  DEBUG util.py:439: bash aarch64 4.4.19-12.el8
  build 1.5 M

  and going to

  DEBUG util.py:439: xz aarch64 5.2.4-3.el8
  build 151 k

  in the below file .. it pulls in all the deps listed below that .. so from:

  DEBUG util.py:439: annobin aarch64 9.35-1.el8
  build 103 k

  to

  DEBUG util.py:439: zstd aarch64 1.4.4-1.el8
  build 302 k

  One of those “Install 175 Packages” in the minimal build root is libmpc.aarch64.

  Compounding your problem .. when you build a new libmpc, it requires mpfr-devel. You have a chicken / egg problem. Minimal buildroot requires libmpc .. you will have to figure out how to build and replace the libmpc with the newer version before you can do anything else.