SUSE Manager/SolverTestcase

From MicroFocusInternationalWiki
Jump to: navigation, search

Debugging yast/zypper dependency issues

Original from bnc#868841

The problematic package

Package: libzypp-testsuite-tool

If it's not included in your distro you find versions in the internal/external build service:

 obs://build.opensuse.org/zypp:*   (openSUSE)
 obs://build.suse.de/Devel:zypp:*  (SLE)

Included is programm called deptestomatic.noui. I use this one as it has no dependencies to yast or GUI. There's also a deptestomatic.multi, which is AFAIK able to feed the testcase into a yast2 package selektor, but I never used it.


A testcase

  • *-package.xml.gz
    Compressed xml containing the data of all available packages; one file per enabled repo. Basically the package versions and their dependencies.
  • solver-system.xml.gz
    Compressed xml containing the data of all installed packages.
  • y2log
    Log of the solver run when creating the testcase. Usually not needed.

Run a testcase

Chdir to the testcase directory and execute:

  $ deptestomatic.noui solver-test.xml
  [debug output filteres]
  >!> Requesting locale de_DE
  >!> Load 86 modaliases.
  >!> Load 0 multiversion specs.
  >!> Installing patch:slessp3-cifs-mount-8655.noarch from channel spacewalk:sles11-sp3-vmware-updates-x86_64
  >!> Installing patch:slessp3-libpixman-1-0-8697.noarch from channel spacewalk:sles11-sp3-vmware-updates-x86_64
  >!> Installing patch:slessp3-gnutls-8949.noarch from channel spacewalk:sles11-sp3-vmware-updates-x86_64
  >!> Locking tgt from channel spacewalk:sles11-sp3-vmware-pool-x86_64
  >!> Locking iscsitarget from channel spacewalk:sles11-sp3-vmware-pool-x86_64
  >!> No valid solution found.
  >!> 2 problems found:
  >!> Problem:
  >!> gtk2-32bit-2.18.9-0.23.1.x86_64 requires libpixman-1.so.0, but this requirement cannot be provided
  >!> uninstallable providers: libpixman-1-0-32bit-0.24.4-0.11.1.x86_64[spacewalk:sles11-sp3-vmware-pool-x86_64]
  >!>    Solution:
  >!>       Following actions will be done:
  >!>       deinstallation of gtk2-32bit-2.18.9-0.23.1.x86_64
  >!>    Solution:
  >!>       do not install patch:slessp3-libpixman-1-0-8697-8697-.noarch
  >!>
  >!>    Solution:
  >!>       break gtk2-32bit-2.18.9-0.23.1.x86_64 by ignoring some of its dependencies
  >!>
  >!> Problem:
  >!> gvfs-backends-1.4.3-0.17.19.1.x86_64 requires libsmbclient.so.0()(64bit), but this requirement cannot be provided
  >!> uninstallable providers: libsmbclient0-3.6.3-0.39.1.x86_64[spacewalk:sles11-sp3-vmware-pool-x86_64]
  >!>    Solution:
  >!>       Following actions will be done:
  >!>       deinstallation of gvfs-backends-1.4.3-0.17.19.1.x86_64
  >!>    Solution:
  >!>       do not install patch:slessp3-cifs-mount-8655-8655-.noarch
  >!>
  >!>    Solution:
  >!>       break gvfs-backends-1.4.3-0.17.19.1.x86_64 by ignoring some of its dependencies
  >!>

That's basically the result of the solver job defined in the <trial> section:

  <trial>
  <install channel="spacewalk:sles11-sp3-vmware-updates-x86_64" kind="patch" name="slessp3-cifs-mount-8655" arch="noarch" version="8655" release="" status="UBTu_"/>
  <install channel="spacewalk:sles11-sp3-vmware-updates-x86_64" kind="patch" name="slessp3-libpixman-1-0-8697" arch="noarch" version="8697" release="" status="UBTu_"/>
  <install channel="spacewalk:sles11-sp3-vmware-updates-x86_64" kind="patch" name="slessp3-gnutls-8949" arch="noarch" version="8949" release="" status="USTu_"/>
  <lock channel="spacewalk:sles11-sp3-vmware-pool-x86_64" kind="package" name="tgt" arch="x86_64" version="0.9.10" release="0.17.1" status="U_Lu_"/>
  <lock channel="spacewalk:sles11-sp3-vmware-pool-x86_64" kind="package" name="iscsitarget" arch="x86_64" version="1.4.20" release="0.34.26" status="U_Lu_"/>
  <addRequire  name="glibc"/>
  </trial>

The zypper command creating the testcase tried to install some patches. There are 2 locked packages (tgt,iscsitarget). A require to glibc is always added to prevent accidental deletion of the whole system.

That's it.


Investigate

There's no recipe. It's usually a mixture of modifying the <trial> sections and searching for packages and their dependencies in the repo data (*-package.xml.gz and solver-system.xml.gz).

The xml files are human readable, but it's no fun if you do it frequently. The libzypp source tree contains a small tool which is able do a few queries (even from a testcase. It's no official tool and not included in any package.

  [https://github.com/openSUSE/libzypp/blob/master/tools/NameReqPrv.cc]
  [g++ -std=c++11 NameReqPrv.cc -lzypp -o NameReqPrv]

  $ NameReqPrv
  Usage: NameReqPrv [--root ROOTDIR] [OPTIONS] NAME... [[OPTIONS] NAME...]...
    Load all enabled repositories (no refresh) and search for
    occurrences of NAME (regex) in package names, provides or
    requires.
    --root   Load repos from the system located below ROOTDIR. If ROOTDIR
	    denotes a sover testcase, the testcase is loaded.
    --installed Process installed packages only.
    -i/-I    turn on/off case insensitive search (default on)
    -n/-N    turn on/off looking for names       (default on)
    -p/-P    turn on/off looking for provides    (default off)
    -r/-R    turn on/off looking for requires    (default off)
    -c/-C    turn on/off looking for conflicts   (default off)
    -o/-O    turn on/off looking for obsoletes   (default off)
    -m/-M    turn on/off looking for recommends  (default off)
    -s/-S    turn on/off looking for supplements (default off)
    -a       short for -n -p -r
    -A       short for -n -P -R
    -D <pkg> dump dependencies of <pkg>

Problems

Problem 1

In the above case I'd start with:

  gtk2-32bit-2.18.9-0.23.1.x86_64 requires libpixman-1.so.0, but this requirement cannot be provided
  uninstallable providers: libpixman-1-0-32bit-0.24.4-0.11.1.x86_64[spacewalk:sles11-sp3-vmware-pool-x86_64]

Get an overview about available libpixman-1-0-32bit versions:

  $ NameReqPrv --root . libpixman-1-0-32bit
  *** Load Testcase from '.'
  {
    sat::repo(spacewalk:sles11-extras-x86_64-vmware-sp3){prio -99.0, size 180}
    sat::repo(spacewalk:sles11-sp2-suse-manager-tools-x86_64-vmware-sp3){prio -99.0, size 158}
    sat::repo(spacewalk:sles11-sp3-vmware-pool-x86_64){prio -99.0, size 2822}
    sat::repo(spacewalk:vmwaretools5.1latest_64bit){prio -99.0, size 43}
    sat::repo(spacewalk:sle11-sdk-sp3-pool-x86_64-vmware-sp3){prio -99.0, size 2761}
    sat::repo(spacewalk:sle11-sdk-sp3-updates-x86_64-vmware-sp3){prio -99.0, size 580}
    sat::repo(spacewalk:sles11-sp3-vmware-updates-x86_64){prio -99.0, size 935}
    sat::repo(spacewalk:he-sles11_3-default-vm){prio -99.0, size 30}
    sat::repo(@System){prio -99.0, size 668}
  }
  libpixman-1-0-32bit [in______] {
    2758  libpixman-1-0-32bit-0.24.4-0.11.1.x86_64  (99)spacewalk:sles11-sp3-vmware-pool-x86_64  SUSE LINUX Products GmbH, Nuernberg, Germany  1368456974
												  nam: libpixman-1-0-32bit
    6802  libpixman-1-0-32bit-0.24.4-0.13.1.x86_64  (99)spacewalk:sles11-sp3-vmware-updates-x86_64  SUSE LINUX Products GmbH, Nuernberg, Germany  1374851227
												    nam: libpixman-1-0-32bit
    7092  libpixman-1-0-32bit-0.24.4-0.15.1.x86_64  (99)spacewalk:sles11-sp3-vmware-updates-x86_64  SUSE LINUX Products GmbH, Nuernberg, Germany  1387583710
												    nam: libpixman-1-0-32bit
    7798  libpixman-1-0-32bit-0.24.4-0.13.1.x86_64  (99)@System                                     SUSE LINUX Products GmbH, Nuernberg, Germany  1374851227
												    nam: libpixman-1-0-32bit
  }

That's strange:

  • Installed is -0.13.1
  • The solver considers -0.11.1 as provider of libpixman-1.so.0; but this would be a downgrade.
  • What about -0.15.1? This would be the latest version.
  • Why isn't it considered?
  • Dependency problem?

Try to install -0.15.1: Edit the <trial> section. Disable the patch install requests and instead require "libpixman-1-0-32bit = 0.24.4-0.15.1":

  <trial>
  <addRequire  name="libpixman-1-0-32bit = 0.24.4-0.15.1"/>
  <!--
    <install channel="spacewalk:sles11-sp3-vmware-updates-x86_64" kind="patch" name="slessp3-cifs-mount-8655" arch="noarch" version="8655" release="" status="UBTu_"/>
    <install channel="spacewalk:sles11-sp3-vmware-updates-x86_64" kind="patch" name="slessp3-libpixman-1-0-8697" arch="noarch" version="8697" release="" status="UBTu_"/>
    <install channel="spacewalk:sles11-sp3-vmware-updates-x86_64" kind="patch" name="slessp3-gnutls-8949" arch="noarch" version="8949" release="" status="USTu_"/>
  -->
  <lock channel="spacewalk:sles11-sp3-vmware-pool-x86_64" kind="package" name="tgt" arch="x86_64" version="0.9.10" release="0.17.1" status="U_Lu_"/>
  <lock channel="spacewalk:sles11-sp3-vmware-pool-x86_64" kind="package" name="iscsitarget" arch="x86_64" version="1.4.20" release="0.34.26" status="U_Lu_"/>
  <addRequire  name="glibc"/>
  </trial>

Run deptestomatic:

  >!> Requesting locale de_DE
  >!> Load 86 modaliases.
  >!> Load 0 multiversion specs.
  >!> Locking tgt from channel spacewalk:sles11-sp3-vmware-pool-x86_64
  >!> Locking iscsitarget from channel spacewalk:sles11-sp3-vmware-pool-x86_64
  >!> No valid solution found.
  >!> 1 problems found:
  >!> Problem:
  >!> gtk2-32bit-2.18.9-0.23.1.x86_64 requires libpixman-1.so.0, but this requirement cannot be provided
  >!> uninstallable providers: libpixman-1-0-32bit-0.24.4-0.11.1.x86_64[spacewalk:sles11-sp3-vmware-pool-x86_64]
  >!>    Solution:
  >!>       Following actions will be done:
  >!>       deinstallation of gtk2-32bit-2.18.9-0.23.1.x86_64
  >!>    Solution:
  >!>       do not ask to install a solvable providing libpixman-1-0-32bit = 0.24.4-0.15.1
  >!>
  >!>    Solution:
  >!>       break gtk2-32bit-2.18.9-0.23.1.x86_64 by ignoring some of its dependencies
  >!>

Even more strange: Updating to -0.15.1 we seem to lose 'libpixman-1.so.0', but that's exactly what should be provided by the libpixman-1-0-32bit package.

Have a closer look at the package dependencies:

  $ NameReqPrv --root . -D libpixman-1-0-32bit
  ...
  ==============================
  (7092)libpixman-1-0-32bit-0.24.4-0.15.1.x86_64(spacewalk:sles11-sp3-vmware-updates-x86_64)
  PROVIDES (1){
    libpixman-1-0-32bit == 0.24.4-0.15.1
  }
  ==============================
  (7798)libpixman-1-0-32bit-0.24.4-0.13.1.x86_64(@System)
  PROVIDES (2){
    libpixman-1.so.0
    libpixman-1-0-32bit == 0.24.4-0.13.1
  }
  PREREQUIRES (4){
  ...

OOps!

libpixman-1-0-32bit-0.24.4-0.15.1 has only the 'self'provides' (name==version). Additional provides about incuded libs are missing.

A broken package?

Checking the sles11-sp3-vmware-updates-x86_64 repos reveals that the package there is fine.


So it's broken metadata? Looks like SUMA does not distribute the libpixman-1.so.0 provides in the metadata it generates. (One could check the matadata in the clients /var/cache/zypp/raw/spacewalk:sles11-sp3-vmware-updates-x86_64 directory to verify this).

Either a fault in SUMS's metadata generation (but then I'd expect more reports like this) or a reposync time error when importing the package into SUMAs database (One should check the server logs or somehow investigate what's actually stored in the DB for this package).


Problem 2

Looks similar (package requires lib):

  $ NameReqPrv --root . -D libsmbclient0
  ...
  ==============================
  (7091)libsmbclient0-3.6.3-0.46.1.x86_64(spacewalk:sles11-sp3-vmware-updates-x86_64)
  PROVIDES (1){
    libsmbclient0 == 3.6.3-0.46.1
  }
  ==============================
  (7820)libsmbclient0-3.6.3-0.42.1.x86_64(@System)
  PROVIDES (3){
    libsmbclient.so.0()(64bit)
    libsmbclient == 3.6.3
    libsmbclient0 == 3.6.3-0.42.1
  }
  PREREQUIRES (5){

Gotcha. Missing provides in -0.46.1