[Rpm-ecosystem] Testing the Dependency Chain

Honza Šilhan jsilhan at redhat.com
Mon Aug 24 13:21:15 UTC 2015

> From: "Pavel Odvody" <podvody at redhat.com>
> On Mon, 2015-08-24 at 11:29 +0200, Michael Schroeder wrote:
> > As you're basically testing libsolv, you might as well use libsolv's
> > testcase support.
> That looks interesting, Michael.
> Can this framework do without actually writing all the specfiles?
> Is there a documentation for the *.t file syntax or do I have to
> reverse-engineer that from tests/* ? :)

The syntax is pretty straightforward. There is some docs of flags [1] or look
into code for SOLVER_(FLAG) constants.
(The generated testcases from `dnf ... --debugsolver` can be seen in

Pavel, what is the aim of the tests?
1) Have a guide for package maintainers, the reference
2) make sure all DNF versions always honor the guide
3) test that RPM works too

For 1) we can do that in Behave (easily readable) and convert it to
libsolv's testcases.
(btw the newest Fedora libsolv build contains the `testsolv` executable.)

If we want to support 2) too then the test should run on DNF
level. Hawkey adds some flags to libsolv by default and some of them
are added by different DNF command. So you would test DNF by
`dnf ... --assumeno --debugsolver` then inspect "debug data/solver.result".
Injecting the different env of installed packages would be harder, maybe
by setting different --installroot.

Having tested all rpm stack 3) you should continue with what you are doing.

It would be a good idea to have these tests written the same way as planned
DNF functional tests. If we don't use Beaker then docker will be a good choice
for creating a separate environment without the need of setup and teardown
(just kill and run again the container). It should not be a problem to run
it under the Jenkins - I've seen some posts mentioning running docker there. 

[1] https://github.com/openSUSE/libsolv/blob/master/doc/libsolv-bindings.txt


More information about the Rpm-ecosystem mailing list