opensuse / libsolv

Library for solving packages and reading repositories

Libsolv

This is libsolv, a free package dependency solver using a satisfiability algorithm.

The code is based on two major, but independent, blocks:

1. Using a dictionary approach to store and retrieve package and dependency information in a fast and space efficient manner.

2. Using satisfiability, a well known and researched topic, for resolving package dependencies.

The sat-solver code has been written to aim for the newest packages, record the decision tree to provide introspection, and also provides the user with suggestions on how to deal with unsolvable problems. It also takes advantage of repository storage to minimize memory usage.

Supported package formats:

• rpm/rpm5

• deb

• arch linux

• haiku

Supported repository formats:

• rpmmd (primary, filelists, comps, deltainfo/presto, updateinfo)

• susetags, suse product formats

• mandriva/mageia (synthesis, info, files)

• arch linux

• red carpet helix format

• haiku

Build instructions

Requires: cmake 2.8.5 or later

mkdir build
cd build
cmake ..
make

libsolv's Issues

typo/grammar errors in libsolv-bindings.3 man page

Patch URL will be provided in a minute...

multiarch support

Does libsolv support multiarches for dependencies calculation?
I think it should look like primary arch + additional arch, if packages exist in primary, then additional ignored. If package has dot arch, then keep additional arch.

reserved identifier violation

I would like to point out that identifiers like "_Chksum" and "_Transaction" do not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

Please provide rudimentary man pages for libsolv tools

Hi,

none of the provide libsolv tools [1] comes with a man page.

Please provide man pages for these tools.

Thanks!
Mike

[1] https://github.com/openSUSE/libsolv/tree/master/tools

Please use version tags on libsolv Git repo

Hi,

my name is Mike Gabriel (sunweaver at debian.org) and I plan to bring zypper and osb-build to Debian (so that people can build openSUSE / SLES et al. packages on Debian systems).

However, for libsolv (which is a build requirement for libzypp) I cannot find any version tags on this Git repo).

Can you please add those tags (at least for 0.6.4) and also continue the maintenance of such tags in the future?

Thanks!
Mike

disabled multiversion pkg is removed when distroupgrade + allowuninstall

Hi,
we are struggling with fixing the last distro-sync Fedora Freeze blocker where kernel packages are going to be removed even when they are excluded.

Without allowuninstall it works:

repo system 0 testtags <inline>
#>=Pkg: kernel-core 1 1 x86_64
#>=Prv: kernel
#>=Pkg: B 1 1 x86_64
repo fedora 0 testtags <inline>
#>=Pkg: kernel-core 2 2 x86_64
#>=Prv: kernel
#>=Pkg: B 1 2 x86_64
system x86_64 rpm system
poolflags implicitobsoleteusescolors
disable pkg kernel-core-1-1.x86_64@system
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job distupgrade all packages
job multiversion provides kernel
result transaction,problems  <inline>
#>install kernel-core-2-2.x86_64@fedora
#>upgrade B-1-1.x86_64@system B-1-2.x86_64@fedora

When allowuninstall flag is set it tries to remove installed multilib package. I expect the result to be the same as in previous example.

repo system 0 testtags <inline>
#>=Pkg: kernel-core 1 1 x86_64
#>=Prv: kernel
#>=Pkg: B 1 1 x86_64
repo fedora 0 testtags <inline>
#>=Pkg: kernel-core 2 2 x86_64
#>=Prv: kernel
#>=Pkg: B 1 2 x86_64
system x86_64 rpm system
poolflags implicitobsoleteusescolors
disable pkg kernel-core-1-1.x86_64@system
solverflags allowvendorchange allowuninstall keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job distupgrade all packages
job multiversion provides kernel
result transaction,problems  <inline>
#>erase kernel-core-1-1.x86_64@system
#>install kernel-core-2-2.x86_64@fedora
#>upgrade B-1-1.x86_64@system B-1-2.x86_64@fedora

I've tried to use lock instead of disable but it gives the errors (we was advised to use considered map along with distroupgrade):

repo system 0 testtags <inline>
#>=Pkg: kernel-core 1 1 x86_64
#>=Prv: kernel
#>=Pkg: B 1 1 x86_64
repo fedora 0 testtags <inline>
#>=Pkg: kernel-core 2 2 x86_64
#>=Prv: kernel
#>=Pkg: B 1 2 x86_64
system x86_64 rpm system
poolflags implicitobsoleteusescolors
solverflags allowvendorchange allowuninstall keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job lock pkg kernel-core-1-1.x86_64@system
job distupgrade all packages
job multiversion provides kernel
result transaction,problems  <inline>
#>install kernel-core-2-2.x86_64@fedora
#>problem 7c1b4d09 info kernel-core-1-1.x86_64 does not belong to a distupgrade repository
#>problem 7c1b4d09 solution 40e697e3 allow kernel-core-1-1.x86_64@system
#>problem 7c1b4d09 solution a2852e8d deljob lock pkg kernel-core-1-1.x86_64@system
#>upgrade B-1-1.x86_64@system B-1-2.x86_64@fedora

I've noticed we even can't mark all but running kernel package as allowuninstall (I expect the result as in first case):

repo system 0 testtags <inline>
#>=Pkg: kernel-core 1 1 x86_64
#>=Prv: kernel
#>=Pkg: B 1 1 x86_64
repo fedora 0 testtags <inline>
#>=Pkg: kernel-core 2 2 x86_64
#>=Prv: kernel
#>=Pkg: B 1 2 x86_64
system x86_64 rpm system
poolflags implicitobsoleteusescolors
disable pkg kernel-core-1-1.x86_64@system
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job distupgrade all packages
job multiversion provides kernel
job allowuninstall name B
result transaction,problems  <inline>
#>erase kernel-core-1-1.x86_64@system
#>install kernel-core-2-2.x86_64@fedora
#>upgrade B-1-1.x86_64@system B-1-2.x86_64@fedora

I've found one workaround but I don't know whether we should always mark counterpart of disabled package to be installed. we still expect excluded packages to not be touched at all during distro-sync (not removed, not installed, not upgraded).

repo system 0 testtags <inline>
#>=Pkg: kernel-core 1 1 x86_64
#>=Prv: kernel
#>=Pkg: B 1 1 x86_64
repo fedora 0 testtags <inline>
#>=Pkg: kernel-core 2 2 x86_64
#>=Prv: kernel
#>=Pkg: B 1 2 x86_64
system x86_64 rpm system
poolflags implicitobsoleteusescolors
disable pkg kernel-core-1-1.x86_64@system
solverflags allowvendorchange allowuninstall keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job distupgrade all packages
job multiversion provides kernel
job install pkg kernel-core-2-2.x86_64
result transaction,problems  <inline>
#>install kernel-core-2-2.x86_64@fedora
#>upgrade B-1-1.x86_64@system B-1-2.x86_64@fedora

Another workaround is to mark all but excluded packages into separated distroupgrade jobs - that works fine.

Is it possible to use distupgrade all in combination with disable pkg and keep disabled packages in place? Can you tell me what's the best approach we should use, please?

provide repo_add_autopattern symbol with -DDEBIAN=1 -DENABLE_SUSEREPO

The libsolv version in Debian will now switch to -DDEBIAN (was: -DSUSE). However, when doing so, the repo_add_autopattern symbols disappears.

In ext/CMakeLists.txt, the relating file repo_autopattern.(c,h) only get built/installed when -DSUSE is used at build time. Wouldn't it make more sense to provide that file if -DENABLE_SUSEREPO is set to 1 / is defined?

Patch will follow soon.

"Replaces" field of DEBIAN package is being lost in some cases

If "Replaces" field value does not have corresponding value in "Conflicts" or ""Breaks" then it is being lost. The value of this fields might need to be stored anyway for later dump into "status" file.

Support for sqlite metadata for rpms in addition to XML

Hey guys,

Currently libsolv accepts only XML for the rpm metadata (filelists, primary etc). That metadata can be presented in the form of sqlite files as well. Would you be open for adding support for sqlite as well? Currently tools like createrepo which is predominantly used for generating repo metadata creates both XML and sqlite files.

Let me give you our use case, could be useful. My team is responsible for services and tools that form a deployment pipeline to different platforms (cloud and on premise). Part of that ecosystem are a couple of services - one that bakes virtual machine images based on a set of repositories, packages and configuration, and another which is essentially a yum repository as a service - it allows our teams to create and maintain isolated repos. The repo service generates the yum metadata for a given repository on the fly when requested. Generating the metadata in the form of sqlite files is very fast for us as the data model behind the service mirrors closely the schema required for sqlite files (all we really do is copy required tables into sqlite, compress it and serve it).

We are migrating our bakery service to use hawkey (and thus libsolv) and librepo in order to speed up the baking process and do smarter things with pulling repo metadata, packages, installation etc. So now we've hit this problem where repositories served by our repo service cannot work with libsolv as it requires XML.

One of the reasons we do not generate XML files in the first place is because yum actually prefers sqlite and is faster using that. I realise the whole new dnf (the new fedora replacement for yum that uses libsolv) ecosystem don't want to just copy what yum does as there are many things wrong with it, however also dnf strives to be backwards compatible and I think this is one of those areas where it is not.

It would be great to get your thoughts on that. Thank you!

Yavor

libsolv seems to ignore the location base set in the primary xml

Hey guys,

We encountered a problem using dnf with one of our repositories. The packages metadata in our primary.xml specifies a location base, like so:

<location href="minimal-1.2.3-9.noarch.rpm" base="https://some-service/packages"/>

Here is the full package snippet for context:

<?xml version="1.0" encoding="UTF-8"?>
<metadata xmlns="http://linux.duke.edu/metadata/common" xmlns:rpm="http://linux.duke.edu/metadata/rpm" packages="1">
<package type="rpm">
  <name>minimal</name>
  <arch>noarch</arch>
  <version epoch="0" ver="1.2.3" rel="9"/>
  <checksum pkgId="YES" type="sha256" rel="9">c49dd53ba485b77753edf80adc04e79a9db29f94a1d89032f5e90efdd50d4be7</checksum>
  <summary>Minimal package</summary>
  <description>Minimal RPM</description>
  <packager/>
  <url/>
  <time build="1411659282" file="1411659282"/>
  <size package="1400" archive="124" installed="0"/>
  <location href="minimal-1.2.3-9.noarch.rpm" base="https://some-service/packages"/>
  <format>
    <rpm:license>Public Domain</rpm:license>
    <rpm:vendor/>
    <rpm:group>Applications/System</rpm:group>
    <rpm:buildhost>buildhost</rpm:buildhost>
    <rpm:sourcerpm>minimal-1.2.3-9.src.rpm</rpm:sourcerpm>
    <rpm:header-range start="280" end="1284"/>
    <rpm:provides>
      <rpm:entry flags="EQ" epoch="0" ver="1.2.3" name="minimal" rel="9"/>
    </rpm:provides>
    <rpm:requires>
      <rpm:entry ver="3.0.4" epoch="0" flags="LE" name="rpmlib(CompressedFileNames)" rel="1"/>
      <rpm:entry ver="4.6.0" epoch="0" flags="LE" name="rpmlib(FileDigests)" rel="1"/>
      <rpm:entry ver="4.0" epoch="0" flags="LE" name="rpmlib(PayloadFilesHavePrefix)" rel="1"/>
      <rpm:entry ver="5.2" epoch="0" flags="LE" name="rpmlib(PayloadIsXz)" rel="1"/>
    </rpm:requires>
  </format>
</package>

</metadata>

By the looks of it dnf does not use that base attribute and is trying to locate the package using the href and the repository url specified in the config. As far as I can see this might be an issue with libsolv. This is where it parses the location tag and extracts the href attribute and then it looks for a xml:base attribute as opposed to just base -

libsolv/ext/repo_rpmmd.c

Line 780 in 6806d31

str = find_attr("xml:base", atts);

Can you confirm that's a bug? Happy to create a pull request if it is.

Thank you
Yavor

No way to set root dir from python

bool add_rpmdb(Repo *ref, int flags = 0) {
repo_add_rpmdb($self, ref, 0, flags);
return 1;
}

doesn't pass the root directory, so, doing a cross install from python is not possible

[RFE] Provides selection callback mechanism

Partly due to what's been experienced in Fedora (see #66) and partly due to my work to introduce DNF into Mageia (see #106 for some patches I've submitted in regards to these efforts) and my efforts to ensure DNF is a strong functional replacement, I've encountered cases where it would be nice if it were possible for the user to be able to select what would satisfy a Requires, when multiple "equally useful" options are available.

I filed a request for the feature in DNF, however it was closed because it isn't possible without a mechanism in libsolv to do it.

It would be nice if this part of the libsolv README became true:

[...] allows to provide the user with suggestions on how to deal with unsolvable problems.

Please consider implementing it.

Make package RECOMMENDS a stronger dependency

Hi,
For Debian packages RECOMMENDS is a strong dependency (but not absolute - https://www.debian.org/doc/debian-policy/ch-relationships.html).
They should be treated as DEPENDS, unless some (new) flag is set that makes libsolv ignores these dependencies (NO_RECOMMENDS maybe).

rename repo2solv.sh to repo2solv

Hi,

I am not sure what the policy in SUSE is for the below, but...

In Debian, it is "forbidden" to have files with file extensions (.sh) in /usr/bin/, /usr/sbin/, etc. For the Debian package of repo2solv I had to rename repo2solv.sh -> repo2solv.

It is ok to reject this request, but maybe it is an approach suitable for libsolv on SUSE, as well.

Greets,
Mike

repo_add_rpmmd: crash when load repo

Program received signal SIGSEGV, Segmentation fault.
__GI__IO_fread (buf=buf@entry=0x7fffffffb650, size=size@entry=1, count=count@entry=8192, fp=fp@entry=0x0) at iofread.c:41
41    _IO_acquire_lock (fp);
(gdb) bt full
#0  __GI__IO_fread (buf=buf@entry=0x7fffffffb650, size=size@entry=1, count=count@entry=8192, fp=fp@entry=0x0) at iofread.c:41
        _IO_acquire_lock_file = <optimized out>
        bytes_requested = 8192
        bytes_read = <optimized out>
#1  0x00007fffefccb4de in fread (__stream=0x0, __n=8192, __size=1, __ptr=0x7fffffffb650) at /usr/include/bits/stdio2.h:295
No locals.
#2  repo_add_rpmmd (repo=repo@entry=0x6d7000, fp=fp@entry=0x0, language=language@entry=0x0, flags=flags@entry=0) at /usr/src/debug/libsolv-0.6.8/ext/repo_rpmmd.c:1185
        pool = 0x6a6d10
        pd = {ret = 0, pool = 0x6a6d10, repo = 0x6d7000, data = 0x6822a0, kind = 0x0, depth = 0, state = STATE_START, statedepth = 0, 
          content = 0x639c80 "H\236\r\367\377\177", lcontent = 0, acontent = 256, docontent = 0, solvable = 0x0, freshens = 0, swtab = {0x7fffefed8940 <stateswitches>, 
            0x7fffefed8a30 <stateswitches+240>, 0x0 <repeats 22 times>, 0x7fffefed8eb0 <stateswitches+1392>, 0x7fffefed8ec8 <stateswitches+1416>, 0x0, 0x0, 0x0, 0x0, 0x0, 
            0x0, 0x0, 0x7fffefed8fb8 <stateswitches+1656>, 0x0, 0x7fffefed8fd0 <stateswitches+1680>, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
            0x7fffefed8ee0 <stateswitches+1440>, 0x7fffefed8ef8 <stateswitches+1464>, 0x7fffefed8f10 <stateswitches+1488>, 0x7fffefed8f28 <stateswitches+1512>, 
            0x7fffefed8f40 <stateswitches+1536>, 0x7fffefed8f58 <stateswitches+1560>, 0x7fffefed8f70 <stateswitches+1584>, 0x7fffefed8f88 <stateswitches+1608>, 
            0x7fffefed8fa0 <stateswitches+1632>, 0x0 <repeats 13 times>}, sbtab = {STATE_START, STATE_START, STATE_SOLVABLE <repeats 12 times>, STATE_START, STATE_START, 
            STATE_SOLVABLE, STATE_SOLVABLE, STATE_SOLVABLE, STATE_SOLVABLE, STATE_SOLVABLE, STATE_SOLVABLE, STATE_SOLVABLE, STATE_SOLVABLE, STATE_SOLVABLE, STATE_DISKUSAGE, 
            STATE_DIRS, STATE_START, STATE_START, STATE_START, STATE_START, STATE_SOLVABLE, STATE_SOLVABLE, STATE_SOLVABLE, STATE_INCLUDES, STATE_SOLVABLE, STATE_EXTENDS, 
            STATE_SOLVABLE <repeats 20 times>, STATE_PROVIDES, STATE_REQUIRES, STATE_OBSOLETES, STATE_CONFLICTS, STATE_RECOMMENDS, STATE_SUPPLEMENTS, STATE_SUGGESTS, 
            STATE_ENHANCES, STATE_FRESHENS, STATE_SOLVABLE, STATE_SOLVABLE}, jd = {tmp = 0x0, tmpl = 0}, tmplang = 0x0, chksumtype = 0, handle = 0, parser = 0x7fffffffada8, 
          dirs = 0x0, ndirs = 0, language = 0x0, langcache = {0 <repeats 185 times>}, lastdir = 0, lastdirstr = 0x0, lastdirstrl = 0, changelog_handle = 0, cspool = {
            strings = 0x70dd00, nstrings = 2, stringspace = 0x6fdcf0 "<NULL>", sstrings = 8, stringhashtbl = 0x0, stringhashmask = 0}, cscache = 0x0, ncscache = 0}
        buf = "<?xml version=\"1.0\" ?><repomd xmlns=\"http://linux.duke.edu/metadata/repo\" xmlns:rpm=\"http://linux.duke.edu/metadata/rpm\">\n <revision>1422641159</revision>\n<data type=\"filelists\">\n  <checksum type=\"sha"...
        l = <optimized out>
        sw = <optimized out>
        data = 0x6822a0
        now = 1007726705
        parser = 0x681b50
#3  0x00007ffff017870a in load_yum_repo (hrepo=0x66f0f0, sack=0x6a85f0) at /usr/src/debug/hawkey/py3/src/sack.c:581
        retval = 0
        pool = 0x6a6d10
        fn_cache = 0x6ccfd0 "/var/tmp/hawkey-brain-XXXXXX/foo.solv"
        fp_primary = 0x0
        repo = 0x6d7000
        fp_repomd = 0x6ba990
        name = 0x6ba2b0 "foo"
        fn_repomd = <optimized out>
        fp_cache = 0x0
#4  hy_sack_load_yum_repo (sack=0x6a85f0, repo=0x66f0f0, flags=0) at /usr/src/debug/hawkey/py3/src/sack.c:980
        build_cache = <optimized out>
        retval = <optimized out>
---Type <return> to continue, or q <return> to quit---
#5  0x00007ffff038f7c1 in load_yum_repo (self=0x7ffff7e83aa8, args=<optimized out>, kwds=<optimized out>) at /usr/src/debug/hawkey/src/python/sack-py.c:447
        _save = 0x6020a0
        kwlist = {0x7ffff0391a84 "repo", 0x7ffff03918d5 "build_cache", 0x7ffff03918e1 "load_filelists", 0x7ffff03918f0 "load_presto", 0x7ffff03918fc "load_updateinfo", 0x0}
        crepo = 0x66f0f0
        build_cache = 0
        load_filelists = 0
        load_presto = 0
        load_updateinfo = 0
        flags = <optimized out>
        ret = 0
#6  0x00007ffff7aedc42 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
No symbol table info available.
#7  0x00007ffff7aecdb6 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
No symbol table info available.
#8  0x00007ffff7aee650 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
No symbol table info available.
#9  0x00007ffff7aee749 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0
No symbol table info available.
#10 0x00007ffff7b07baf in run_mod () from /lib64/libpython2.7.so.1.0
No symbol table info available.
#11 0x00007ffff7b08dd2 in PyRun_FileExFlags () from /lib64/libpython2.7.so.1.0
No symbol table info available.
#12 0x00007ffff7b09fe7 in PyRun_SimpleFileExFlags () from /lib64/libpython2.7.so.1.0
No symbol table info available.
#13 0x00007ffff7b1b6ba in Py_Main () from /lib64/libpython2.7.so.1.0
No symbol table info available.
#14 0x00007ffff6d359e0 in __libc_start_main (main=0x4006f0 <main>, argc=2, argv=0x7fffffffddc8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fffffffddb8) at libc-start.c:289
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -3081374843382873715, 4196096, 140737488346560, 0, 0, 3081375393844216205, 3081355778622669197}, mask_was_saved = 0}}, 
          priv = {pad = {0x0, 0x0, 0x400800 <__libc_csu_init>, 0x7fffffffddc8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 4196352}}}
        not_first_call = <optimized out>
#15 0x0000000000400729 in _start ()
No symbol table info available.

==6593== Invalid read of size 4
==6593==    at 0x5BA0BED: fread (iofread.c:41)
==6593==    by 0xD5544DD: UnknownInlinedFun (stdio2.h:295)
==6593==    by 0xD5544DD: repo_add_rpmmd (repo_rpmmd.c:1185)
==6593==    by 0xD0A2709: load_yum_repo (sack.c:581)
==6593==    by 0xD0A2709: hy_sack_load_yum_repo (sack.c:980)
==6593==    by 0xCE857C0: load_yum_repo (sack-py.c:447)
==6593==    by 0x4F19C41: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==6593==    by 0x4F18DB5: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==6593==    by 0x4F1A64F: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==6593==    by 0x4F1A748: PyEval_EvalCode (in /usr/lib64/libpython2.7.so.1.0)
==6593==    by 0x4F33BAE: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6593==    by 0x4F34DD1: PyRun_FileExFlags (in /usr/lib64/libpython2.7.so.1.0)
==6593==    by 0x4F35FE6: PyRun_SimpleFileExFlags (in /usr/lib64/libpython2.7.so.1.0)
==6593==    by 0x4F476B9: Py_Main (in /usr/lib64/libpython2.7.so.1.0)
==6593==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Loading filelist.xml.gz is extremely slow

Follow up on this bug

It's about dnf makecache which, among other things, converts filelist.xml.gz to filenames.solvx. The whole process on Fedora repositories takes a lot of time - sometimes over 10 minutes, using 100% CPU at that time. Example stats (take a look at the linked BZ for more of them):

[user@f22test ~]$ time sudo dnf clean all
Cleaning repos: fedora test updates qubes-vm-r3.0-current-testing
              : qubes-vm-r3.0-current
Cleaning up Everything

real    0m0.510s
user    0m0.329s
sys 0m0.159s
[user@f22test ~]$ time sudo dnf check-update
Fedora 22 - x86_64                               10 MB/s |  41 MB     00:04    
######### (here it takes over 10 minutes) #######
Test                                            1.2 MB/s |  10 kB     00:00    
Fedora 22 - x86_64 - Updates                    8.8 MB/s |  19 MB     00:02    
Qubes OS Repository for VM (updates-testing)    3.8 kB/s | 257  B     00:00    
Qubes OS Repository for VM (updates)            3.6 kB/s | 257  B     00:00    
Last metadata expiration check performed 0:00:00 ago on Fri Oct 30 15:33:52 2015.

real    12m43.331s
user    0m46.187s
sys 11m35.080s

But given a closer look at it, the most time is spend on system calls, and especially one of them: mremap. Strace:

mremap(0x7fb16133d000, 46936064, 46940160, MREMAP_MAYMOVE) = 0x7fb15933c000
mremap(0x7fb15933c000, 46940160, 46944256, MREMAP_MAYMOVE) = 0x7fb16133b000
mremap(0x7fb16133b000, 46944256, 46948352, MREMAP_MAYMOVE) = 0x7fb15933a000
mremap(0x7fb15933a000, 46948352, 46952448, MREMAP_MAYMOVE) = 0x7fb161339000
mremap(0x7fb161339000, 46952448, 46956544, MREMAP_MAYMOVE) = 0x7fb159338000
mremap(0x7fb159338000, 46956544, 46960640, MREMAP_MAYMOVE) = 0x7fb161337000
mremap(0x7fb161337000, 46960640, 46964736, MREMAP_MAYMOVE) = 0x7fb159336000
mremap(0x7fb159336000, 46964736, 46968832, MREMAP_MAYMOVE) = 0x7fb161335000
mremap(0x7fb161335000, 46968832, 46972928, MREMAP_MAYMOVE) = 0x7fb159334000
mremap(0x7fb159334000, 46972928, 46977024, MREMAP_MAYMOVE) = 0x7fb161333000
mremap(0x7fb161333000, 46977024, 46981120, MREMAP_MAYMOVE) = 0x7fb159332000
mremap(0x7fb159332000, 46981120, 46985216, MREMAP_MAYMOVE) = 0x7fb161331000

According to gdb, the call trace is:

#0  0x00007fb18612034a in mremap () from /lib64/libc.so.6
#1  0x00007fb18609a8a4 in mremap_chunk () from /lib64/libc.so.6
#2  0x00007fb1860a1848 in realloc () from /lib64/libc.so.6
#3  0x00007fb17347ac0e in solv_realloc () from /lib64/libsolv.so.0
#4  0x00007fb17346d1d9 in repodata_serialize_key.isra ()
   from /lib64/libsolv.so.0
#5  0x00007fb1734780f4 in repodata_internalize () from /lib64/libsolv.so.0
#6  0x00007fb17321efd1 in repo_add_rpmmd () from /lib64/libsolvext.so.0

mremap-ing that large memory chunk by 4kb at a time, up to over 100MB, which I guess require also copying all the remapped memory area at every 4kb increase, doesn't sound like the most efficient way, at least.

Conflicts between glib2-2.46.1-2.fc23.i686 and glib2-2.46.0-1.fc23.x86_64

Trying to update on f23 gives the following full output, asked on fedora channel and told me is a libsolv bug:

The downloaded packages were saved in cache till the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
file /usr/share/doc/glib2/README from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/doc/glib2/NEWS from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/locale/cs/LC_MESSAGES/glib20.mo from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/locale/eu/LC_MESSAGES/glib20.mo from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/locale/sr/LC_MESSAGES/glib20.mo from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/locale/sr@latin/LC_MESSAGES/glib20.mo from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/locale/vi/LC_MESSAGES/glib20.mo from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/man/man1/gapplication.1.gz from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/man/man1/gdbus.1.gz from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/man/man1/gio-querymodules.1.gz from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/man/man1/glib-compile-schemas.1.gz from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/man/man1/gsettings.1.gz from install of glib2-2.46.1-2.fc23.i686 conflicts with file from package glib2-2.46.0-1.fc23.x86_64
file /usr/share/man/man5/cert8.db.5.gz from install of nss-3.20.1-1.0.fc23.i686 conflicts with file from package nss-3.20.0-1.0.fc23.x86_64
file /usr/share/man/man5/cert9.db.5.gz from install of nss-3.20.1-1.0.fc23.i686 conflicts with file from package nss-3.20.0-1.0.fc23.x86_64
file /usr/share/man/man5/key3.db.5.gz from install of nss-3.20.1-1.0.fc23.i686 conflicts with file from package nss-3.20.0-1.0.fc23.x86_64
file /usr/share/man/man5/key4.db.5.gz from install of nss-3.20.1-1.0.fc23.i686 conflicts with file from package nss-3.20.0-1.0.fc23.x86_64
file /usr/share/man/man5/pkcs11.txt.5.gz from install of nss-3.20.1-1.0.fc23.i686 conflicts with file from package nss-3.20.0-1.0.fc23.x86_64
file /usr/share/man/man5/secmod.db.5.gz from install of nss-3.20.1-1.0.fc23.i686 conflicts with file from package nss-3.20.0-1.0.fc23.x86_64
file /usr/share/doc/harfbuzz/NEWS from install of harfbuzz-1.0.6-1.fc23.i686 conflicts with file from package harfbuzz-1.0.4-1.fc23.x86_64
file /usr/share/doc/pango/NEWS from install of pango-1.38.1-1.fc23.i686 conflicts with file from package pango-1.38.0-1.fc23.x86_64
file /usr/share/man/man1/pango-view.1.gz from install of pango-1.38.1-1.fc23.i686 conflicts with file from package pango-1.38.0-1.fc23.x86_64
file /usr/share/doc/gnutls/NEWS from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/cs/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/de/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/en@boldquot/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/en@quot/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/eo/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/fi/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/fr/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/it/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/ms/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/nl/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/pl/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/sv/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/uk/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/vi/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/locale/zh_CN/LC_MESSAGES/gnutls.mo from install of gnutls-3.4.6-1.fc23.i686 conflicts with file from package gnutls-3.4.5-1.fc23.x86_64
file /usr/share/doc/libwebp/AUTHORS from install of libwebp-0.4.4-1.fc23.i686 conflicts with file from package libwebp-0.4.3-3.fc23.x86_64
file /usr/share/doc/libwebp/README from install of libwebp-0.4.4-1.fc23.i686 conflicts with file from package libwebp-0.4.3-3.fc23.x86_64
file /usr/share/doc/libwebp/NEWS from install of libwebp-0.4.4-1.fc23.i686 conflicts with file from package libwebp-0.4.3-3.fc23.x86_64
file /usr/share/doc/libwebp/PATENTS from install of libwebp-0.4.4-1.fc23.i686 conflicts with file from package libwebp-0.4.3-3.fc23.x86_64

Error Summary

GLib dependency?

We're discussing adding a GLib dependency for hawkey (a libsolv wrapper). Currently librepo already depends on GLib, and higher level libraries such as https://github.com/hughsie/libhif (which is itself consumed by PackageKit and https://github.com/projectatomic/rpm-ostree ) all use GLib.

There are quite a number of cleanups that could occur with a GLib dependency:

• the MD5, SHA1, and SHA2 copies
• solv_validutf8 -> g_utf8_validate
• Queue is just GQueue with int as a data value

etc. Would you consider a patch for this?

crash with data_skip on Fedora 21+22 using dnf

Hello can the developer take an look on it?
Her the original reports with debug information:
https://bugzilla.redhat.com/show_bug.cgi?id=1225975
https://bugzilla.redhat.com/show_bug.cgi?id=1175906

in commit 98352a5 orphans block distroupgrade

Hi,
since commit 98352a5 in libsolv, following tests no longer pass in Hawkey. It seems orphans abort distroupgrade transaction.

• test_goal_distupgrade_all_keep_arch expected result

repo system 0 testtags <inline>
#>=Pkg: baby 6:5.0 11 x86_64
#>=Pkg: dog 1 1 x86_64
#>=Con: custard = 1.1
#>=Pkg: flying 2 9 noarch
#>=Req: P-lib >= 3
#>=Pkg: fool 1 3 noarch
#>=Prv: fool <= 1-3
#>=Prv: /no/answers
#>=Pkg: gun 4 1 i686
#>=Pkg: jay 5.0 0 x86_64
#>=Pkg: jay 6.0 0 x86_64
#>=Pkg: pilchard 1.2.3 1 i686
#>=Pkg: pilchard 1.2.3 1 x86_64
#>=Pkg: penny 4 1 noarch
#>=Prv: P = 3-3
#>=Sum: in my eyes
#>=Pkg: penny-lib 4 1 x86_64
#>=Prv: P-lib = 3-3
#>=Sum: in my ears
#>=Pkg: pigs 4 0 noarch
#>=Req: /usr/bin/away
#>=Pkg: tour 4 0 noarch
#>=Prv: /usr/bin/away
repo main 0 testtags <inline>
#>=Pkg: baby 6:4.9 3 x86_64
#>=Sup: flying
#>=Pkg: flying 3 0 noarch
#>=Req: P-lib
#>=Rec: baby
#>=Sug: walrus
#>=Pkg: fool 1 3 noarch
#>=Prv: fool <= 1-3
#>=Pkg: hello 1 1 noarch
#>=Req: goodbye
#>=Pkg: jay 4.9 0 x86_64
#>=Pkg: jay 5.0 0 x86_64
#>=Pkg: jay 6.0 0 x86_64
#>=Pkg: penny 4 1 noarch
#>=Prv: P = 3-3
#>=Sum: in my eyes
#>=Pkg: penny-lib 4 1 x86_64
#>=Prv: P-lib = 3-3
#>=Pkg: penny-lib 4 1 i686
#>=Prv: P-lib = 3-3
#>=Sum: in my ears
#>=Pkg: penny-lib-devel 4 1 x86_64
#>=Pkg: semolina 2 0 x86_64
#>=Pkg: semolina 2 0 i686
#>=Pkg: walrus 2 5 noarch
#>=Prv: walrus <= 2-5
#>=Req: semolina = 2
#>=Req: fool
#>=Enh: flying
repo updates 0 testtags <inline>
#>=Pkg: dog 1 2 i686
#>=Con: custard = 1.2
#>=Pkg: dog 1 2 x86_64
#>=Con: custard = 1.2
#>=Pkg: fool 1 5 noarch
#>=Prv: fool <= 1-5
#>=Prv: fool-lib = 3.3
#>=Obs: penny <= 4-1
#>=Obs: baby = 6:4.8-3
#>=Pkg: flying 3 0 noarch
#>=Req: P-lib
#>=Pkg: flying 3.1 0 x86_64
#>=Req: P-lib
#>=Pkg: flying 3.2 0 noarch
#>=Req: P-lib >= 3-4
#>=Pkg: pilchard 1.2.4 1 i686
#>=Pkg: pilchard 1.2.4 1 x86_64
#>=Pkg: pilchard 1.2.4 2 x86_64
#>=Pkg: walrus 2 6 noarch
#>=Prv: walrus <= 2-5
#>=Req: semolina = 2
#>=Req: fool
system x86_64 rpm system
poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job distupgrade all packages
result transaction,problems <inline>
#>downgrade baby-6:5.0-11.x86_64@system baby-6:4.9-3.x86_64@main
#>erase penny-4-1.noarch@system fool-1-5.noarch@updates
#>upgrade dog-1-1.x86_64@system dog-1-2.x86_64@updates
#>upgrade flying-2-9.noarch@system flying-3.1-0.x86_64@updates
#>upgrade fool-1-3.noarch@system fool-1-5.noarch@updates
#>upgrade pilchard-1.2.3-1.i686@system pilchard-1.2.4-1.i686@updates
#>upgrade pilchard-1.2.3-1.x86_64@system pilchard-1.2.4-1.x86_64@updates

after 98352a5 it gives:

problem 853547db info problem with installed package gun-4-1.i686
problem 853547db solution 1e110a85 allow gun-4-1.i686@system
problem 853547db solution ea6b6fda erase gun-4-1.i686@system
problem adac2a93 info problem with installed package pigs-4-0.noarch
problem adac2a93 solution b3c2d789 erase pigs-4-0.noarch@system
problem adac2a93 solution bf886ad9 allow pigs-4-0.noarch@system
problem f637f894 info problem with installed package tour-4-0.noarch
problem f637f894 solution aec7fe8d allow tour-4-0.noarch@system
problem f637f894 solution e7c45b56 erase tour-4-0.noarch@system

• test_goal_distupgrade_all expected result:

repo system 0 testtags <inline>
#>=Pkg: baby 6:5.0 11 x86_64
#>=Pkg: dog 1 1 x86_64
#>=Con: custard = 1.1
#>=Pkg: flying 2 9 noarch
#>=Req: P-lib >= 3
#>=Pkg: fool 1 3 noarch
#>=Prv: fool <= 1-3
#>=Prv: /no/answers
#>=Pkg: gun 4 1 i686
#>=Pkg: jay 5.0 0 x86_64
#>=Pkg: jay 6.0 0 x86_64
#>=Pkg: pilchard 1.2.3 1 i686
#>=Pkg: pilchard 1.2.3 1 x86_64
#>=Pkg: penny 4 1 noarch
#>=Prv: P = 3-3
#>=Sum: in my eyes
#>=Pkg: penny-lib 4 1 x86_64
#>=Prv: P-lib = 3-3
#>=Sum: in my ears
#>=Pkg: pigs 4 0 noarch
#>=Req: /usr/bin/away
#>=Pkg: tour 4 0 noarch
#>=Prv: /usr/bin/away
repo main 0 testtags <inline>
#>=Pkg: baby 6:4.9 3 x86_64
#>=Sup: flying
#>=Pkg: flying 3 0 noarch
#>=Req: P-lib
#>=Rec: baby
#>=Sug: walrus
#>=Pkg: fool 1 3 noarch
#>=Prv: fool <= 1-3
#>=Pkg: hello 1 1 noarch
#>=Req: goodbye
#>=Pkg: jay 4.9 0 x86_64
#>=Pkg: jay 5.0 0 x86_64
#>=Pkg: jay 6.0 0 x86_64
#>=Pkg: penny 4 1 noarch
#>=Prv: P = 3-3
#>=Sum: in my eyes
#>=Pkg: penny-lib 4 1 x86_64
#>=Prv: P-lib = 3-3
#>=Pkg: penny-lib 4 1 i686
#>=Prv: P-lib = 3-3
#>=Sum: in my ears
#>=Pkg: penny-lib-devel 4 1 x86_64
#>=Pkg: semolina 2 0 x86_64
#>=Pkg: semolina 2 0 i686
#>=Pkg: walrus 2 5 noarch
#>=Prv: walrus <= 2-5
#>=Req: semolina = 2
#>=Req: fool
#>=Enh: flying
system x86_64 rpm system
poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job distupgrade all packages
result transaction,problems <inline>
#>downgrade baby-6:5.0-11.x86_64@system baby-6:4.9-3.x86_64@main
#>upgrade flying-2-9.noarch@system flying-3-0.noarch@main

after 98352a5 it gives:
(one repo less than in previous example but additionally dog orphan package blocks transaction)

problem 853547db info problem with installed package gun-4-1.i686
problem 853547db solution 1e110a85 allow gun-4-1.i686@system
problem 853547db solution ea6b6fda erase gun-4-1.i686@system
problem a4f9229f info problem with installed package dog-1-1.x86_64
problem a4f9229f solution f0c2b083 allow dog-1-1.x86_64@system
problem a4f9229f solution ff5dc0fb erase dog-1-1.x86_64@system
problem acf8a29c info problem with installed package pilchard-1.2.3-1.i686
problem acf8a29c solution 69ce58cc allow pilchard-1.2.3-1.i686@system
problem adac2a93 info problem with installed package pigs-4-0.noarch
problem adac2a93 solution b3c2d789 erase pigs-4-0.noarch@system
problem adac2a93 solution bf886ad9 allow pigs-4-0.noarch@system
problem f637f894 info problem with installed package tour-4-0.noarch
problem f637f894 solution aec7fe8d allow tour-4-0.noarch@system
problem f637f894 solution e7c45b56 erase tour-4-0.noarch@system

• test_goal_installonly_limit_with_modules expected result:

repo system 0 testtags <inline>
#>=Pkg: k 1 0 x86_64
#>=Pkg: k-m 1 0 x86_64
#>=Req: k = 1-0
#>=Pkg: k-freak-1-0 1 0 x86_64
#>=Req: k = 1-0
#>=Pkg: k 1 1 x86_64
#>=Pkg: k-m 1 1 x86_64
#>=Req: k = 1-1
#>=Pkg: k 2 0 x86_64
#>=Pkg: k-m 2 0 x86_64
#>=Req: k = 2-0
#>=Pkg: k 3 0 x86_64
#>=Pkg: k-m 3 0 x86_64
#>=Req: k = 3-0
repo installonly 0 testtags <inline>
#>=Pkg: k 3 1 x86_64
#>=Pkg: k-m 3 1 x86_64
#>=Req: k = 3-1
#>=Pkg: k 3 6 x86_64
#>=Pkg: k-m 3 6 x86_64
#>=Req: k = 3-6
system x86_64 rpm system
poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job distupgrade all packages
job multiversion provides k
job multiversion provides k-m
result transaction,problems <inline>
#>install k-3-6.x86_64@installonly
#>install k-m-3-6.x86_64@installonly

after 98352a5 it gives:

problem 4745eca0 info problem with installed package k-freak-1-0-1-0.x86_64
problem 4745eca0 solution ab4073c9 erase k-freak-1-0-1-0.x86_64@system
problem 4745eca0 solution ecf56dd5 allow k-freak-1-0-1-0.x86_64@system

/cc @mluscon

ABI break in libsolv 0.6.x compared to 0.1.x without soversion bump

We've been using libsolv 0.1.x and libzypp 12.16.x for some time in Mer. When upgrading to libzypp 14.35.0, we also upgraded libsolv to 0.6.8, but as libsolv 0.6.8 still has the same soversion as 0.1.x, in some cases the new libzypp (14.35.0) was installed with the old libzypp (0.1.x), which caused symbol lookup error.

We worked around this with two relationships:

https://git.merproject.org/mer-core/libzypp/blob/master/rpm/libzypp.spec#L21
Requires: libsolv0 >= 0.6.8

https://git.merproject.org/mer-core/libsolv/blob/master/rpm/libsolv.spec#L69
Conflicts: libzypp < 14.35.0

However, I guess in this case, the soversion of libsolv should have been bumped? Then again, the 0.x version might suggest that there's no ABI compatibility guarantee for libsolv yet(?).

Compilation fails with ENABLE_STATIC option

I am trying to build static version of the library on SLE11 SP1
cmake .. -DENABLE_STATIC=1 // Everything goes fine
make // Fails while compiling tools/deltainfoxml2solv

Error ...
......
......
Linking C static library libtoolstuff.a
[ 85%] Built target toolstuff
Scanning dependencies of target deltainfoxml2solv
[ 86%] Building C object tools/CMakeFiles/deltainfoxml2solv.dir/deltainfoxml2solv.o
make[2]: *** No rule to make target ext/libsolvext.so.0', needed bytools/deltainfoxml2solv'. Stop.
make[1]: *** [tools/CMakeFiles/deltainfoxml2solv.dir/all] Error 2
make: *** [all] Error 2

Removing auto-installed orphaned packages

How to achieve removing auto-installed orphaned DEBIAN packages? Seems there is no mechanism for it in libsolv.
I can create a patch to store auto-installed property of STATUS file in solvable, but I don't know what to do with it next.

Invalid free in pool_free (pool.c:120)

While investigating a yast crash on openSUSE 13.1, valgrind points me to the line solv_free(pool->languages); in pool_free. It seems to me that if nlanguages == 0 then that pointer is uninitialized. I base that on pool_set_languages skipping it.

Workaround: export LANG=en_US.UTF-8 (it was empty in my JeoS before)

libsolv0: shlib-calls-exit usr/lib/x86_64-linux-gnu/libsolv.so.0

Hi!

The package integrity check tool "lintian" for Debian reports the below issue.

Can you please confirm that the exit() call in libsolv is intended? Otherwise, this issue needs a fix in upstream.

X: libsolv0: shlib-calls-exit usr/lib/x86_64-linux-gnu/libsolv.so.0
N:
N: The listed shared library calls the C library exit() or _exit()
N: functions.
N:
N: In the case of an error, the library should instead return an
N: appropriate error code to the calling program which can then determine
N: how to handle the error, including performing any required clean-up.
N:
N: In most cases, removing the call should be discussed with upstream,
N: particularly as it may produce an ABI change.
N:
N: Severity: wishlist, Certainty: possible
N:
N: Check: shared-libs, Type: binary, udeb
N:
N: This tag is marked experimental, which means that the code that
N: generates it is not as well-tested as the rest of Lintian and might
N: still give surprising results. Feel free to ignore experimental tags
N: that do not seem to make sense, though of course bug reports are always
N: welcome.
N:

Thanks for investigating!
Mike

mechanism to prefer some repo in distroupgrade

Hi,
we're dealing with system-upgrades and we would like to prefer fedora repo and in case of package conflicts rather remove the third party package.

Could I by changing repository priority / subpriority and using SOLVER_DISTUPGRADE|SOLVER_SOLVABLE_ALL achieve that?
I understand priorities like when one package of some name is about to be installed then it will choose the one with higher priority. This is a bit different case, we want packages from fedora to stay installed rather than conflicting packages of different names from other repo.

The other solution that I thought about is to iterate over all installed packages and for the names that are in fedora repo, do SOLVER_SOLVABLE|SOLVER_DISTUPGRADE otherwise SOLVER_SOLVABLE|SOLVER_DISTUPGRADE|SOLVER_WEAK

Or is there any other libsolv mechanism that I am missing?

compiling with -DARCHLINUX fails

When building for ArchLinux with -DARCHLINUX, the build fails with following error:

Linking C executable solv                                                                                                     
CMakeFiles/solv.dir/solv.o: In function `main':                                                                               
solv.c:(.text.startup+0x1db): undefined reference to `read_repoinfos'
collect2: error: ld returned 1 exit status
examples/CMakeFiles/solv.dir/build.make:90: recipe for target 'examples/solv' failed
make[2]: *** [examples/solv] Error 1
CMakeFiles/Makefile2:692: recipe for target 'examples/CMakeFiles/solv.dir/all' failed
make[1]: *** [examples/CMakeFiles/solv.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Looking at the example/solv.c file, it seems defined(ARCHLINUX) isn't present in the code so read_repoinfos is never defined.

The "workaround" here is to compile without explicitly defining a system (with ENABLE_ARCHREPO=1), so the repo* functions are defined (but empty). Is this intended, or is the Arch Linux code simply missing at the moment?

Code stuck while

I found a resolution operation which causes a huge CPU usage and seems to be endless. The code reproducing the issue can be found inside of this gist.

The resolution takes almost 30 seconds on my machine, then it hangs when looking for the 11th resolution problem.

write man page /usr/bin/solv

The solv executable currently (0.6.10) lacks a man page. Discovered while updating libsolv in Debian.

Unable to obtain solvable filelists

How can one obtain the filelist of a solvable? Tried solvable.lookup_idarray(solv.SOLVABLE_FILELIST)

CMake detects Python3 = 3.4.3+ and fails

I use Ubuntu wily and found this problem. It is currently under heavy development and unreleased - However, I would love to see the CMake script more failsave for cases where a "+" appears in the version string. (At least I beleave this is the problem here.)

-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.4m.so (found version "3.4.3+") 
CMake Error at bindings/python/CMakeLists.txt:4 (FIND_PACKAGE):
  find_package called with invalid argument "3.4.3+"


-- Python executable: 
-- Python installation dir: 
CMake Error at bindings/python/CMakeLists.txt:31 (INSTALL):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  "bindings_python".


CMake Error at bindings/python/CMakeLists.txt:32 (INSTALL):
  install FILES given no DESTINATION!

musl-libc compatibility

libsolv refuses to compile under MUSL-libc due to fopencookie/funopen in etx/solv_xfopen.c MUSL does not seem to have funopen support. Compilation fails with "error Need to implement custom I/O".

ext/repo_arch.c:297: bad while test ?

libsolv/ext/repo_arch.c:297:23: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op]

while (*line == ' ' && *line == '\t')

Suggest swap && for ||

Support simultaneous binding builds for Python 2 _and_ Python 3

HI,

I spent the night with finding a patch that will introduce support to libsolv for simultaneously building bindings for Python2 and Python3.

Patch will come during the day...

Mike (aka sunweaver at debian.org)

The API man pages contain several grammar and spelling errors

The API man pages contain several grammar and spelling errors.

Patch comes within the day...

archrepo2solv is failing

When building with ENABLE_ARCHREPO=1, the archrepo2solv tool doesn't seem to work:

"The archrepo2solv tool reads Arch Linux repository data (core.db) from stdin, and writes it as solv file to standard output."

However, I'm not able to use this tool unless I uncompress the core.db/extra.db files first, and use the -l option of archrepo2solv to generate the solv file. That option is originally intended for the local repository (sync database).

This issue might be closely related to #60.

distupgrade all + keeporphans + allowuninstall -> deletes orhans

Hi,
when I distupgrade all packages that doesn't have conflicts it will keep the orphans installed.
So far so good:

repo system 0 testtags <inline>
#>=Pkg: A 1 1 x86_64
#>=Pkg: C 1 1 x86_64
repo fedora 0 testtags <inline>
#>=Pkg: A 1 2 x86_64
system x86_64 rpm system
poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job distupgrade all packages
result transaction,problems <inline>
#>upgrade A-1-1.x86_64@system A-1-2.x86_64@fedora

then when I add allowuninstall solver flag to solve conflicts, it will take away orphans too.
(I expect the C to stay installed)

repo system 0 testtags <inline>
#>=Pkg: A 1 1 x86_64
#>=Pkg: B 1 1 x86_64
#>=Pkg: C 1 1 x86_64
#>=Pkg: D 1 1 x86_64
repo fedora 0 testtags <inline>
#>=Pkg: A 1 2 x86_64
#>=Pkg: B 1 2 x86_64
#>=Con: D
system x86_64 rpm system
poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes allowuninstall
job distupgrade all packages
result transaction,problems <inline>
#>upgrade A-1-1.x86_64@system A-1-2.x86_64@fedora
#>erase D-1-1.x86_64@system
#>upgrade B-1-1.x86_64@system B-1-2.x86_64@fedora

Is it intentional? shouldn't allowuninstall job for all packages be the same as allowuninstall solver flag?
This works fine:

repo system 0 testtags <inline>
#>=Pkg: A 1 1 x86_64
#>=Pkg: B 1 1 x86_64
#>=Pkg: C 1 1 x86_64
#>=Pkg: D 1 1 x86_64
repo fedora 0 testtags <inline>
#>=Pkg: A 1 2 x86_64
#>=Pkg: B 1 2 x86_64
#>=Con: D
system x86_64 rpm system
poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes
job allowuninstall name D
job allowuninstall name C
job distupgrade all packages
result transaction,problems <inline>
#>erase D-1-1.x86_64@system
#>upgrade A-1-1.x86_64@system A-1-2.x86_64@fedora
#>upgrade B-1-1.x86_64@system B-1-2.x86_64@fedora

I don't have a problem with is behavior as we can achieve what we want with ^ workaround. I wasn't sure whether it's a bug or not and wondering how does zypper do distro-sync with resolving conflicts and keeping the orphaned packages installed proper way.

Rules of picking package by provide in Fedora

Hi, does libsolv try to find the smallest set of packages? Or can we add any custom function to solver which would add preference to package to be picked as the next rule? yum chooses next package by some ugly rules. In a few jobs dnf picks more dependencies than yum and people complain about it. example:

repo system 0 testtags <inline>
repo available 0 testtags <inline>
#>=Pkg: A 1 1 x86_64
#>=Req: B
#>=Req: C
#>=Prv: P
#>=Pkg: A 2 1 x86_64
#>=Req: B
#>=Req: C
#>=Pkg: A-runtime 2 1 x86_64
#>=Prv: P
#>=Pkg: B 1 1 x86_64
#>=Pkg: C 1 1 x86_64
#>=Pkg: B 1 0 noarch
system x86_64 rpm system
job install provides P
result transaction,problems <inline>

actual result:

install A-1-1.x86_64@available
install B-1-1.x86_64@available
install C-1-1.x86_64@available

desired result:

install A-runtime-2-1.x86_64@available

Support configurable include directory

For building a multi-arch compliant -dev packages in Debian, the packages' header files are required to be installed into a multi-arch compliant location (i.e. /usr/include//).

At the time being libsolv does not support a multi-arch compliant installation target for .h files.

Patch comes within the day...

Mike (aka sunweaver at debian.org)

SOLVER_FLAG_NO_INFARCHCHECK not working as expected

The documentation states:

SOLVER_FLAG_NO_INFARCHCHECK::
Turn off the inferior architecture checking that is normally done
by the solver. Normally, the solver allows only the installation
of packages from the "best" architecture if a package is available
for multiple architectures.

Suppose pool_setarch() is called with "x86_64" and there are two packages available for installation:
A 1-0 with architecture x86_64
A 2-0 with architecture i686

Without SOLVER_FLAG_NO_INFARCHCHECK set, solving with a job to install A results in a transaction saying to install A 1-0 as expected since x86_64 is the best architecture.
However, with SOLVER_FLAG_NO_INFARCHCHECK set for the solver and a job to install A, I expected the inferior architecture checking to be turned off and A 2-0 to be installed because it has the better version. Instead, A 1-0 is installed. To be sure that it was possible to install A 2-0, I also tried giving a job to explicitly install a A 2-0 which worked.

Is there something that I'm missing or misunderstanding?

Here is the previous example as a test case (which will fail on the last line since A-1-0.x86_64 is chosen to be installed instead):

repo system 0 testtags <inline>
repo test 0 testtags <inline>
#>=Pkg: A 1 0 x86_64
#>=Pkg: A 2 0 i686
system x86_64 rpm system

job install name A
result transaction,problems <inline>
#>install A-1-0.x86_64@test

nextjob
job install name A = 2
result transaction,problems <inline>
#>install A-2-0.i686@test

nextjob
solverflags noinfarchcheck
job install name A
result transaction,problems <inline>
#>install A-2-0.i686@test

definition of GET_USERINSTALLED_NAMEARCH missing

Hi, during compiling with -DENABLE_DEBIAN=1 flag error occurs:

/home/jsilhan/Documents/libsolv/ext/repo_deb.c: In function ‘pool_deb_get_autoinstalled’:
/home/jsilhan/Documents/libsolv/ext/repo_deb.c:658:21: error: ‘GET_USERINSTALLED_NAMEARCH’ undeclared (first use in this function)
        if ((flags & GET_USERINSTALLED_NAMEARCH) != 0)
                     ^
/home/jsilhan/Documents/libsolv/ext/repo_deb.c:658:21: note: each undeclared identifier is reported only once for each function it appears in

Probably missing definition of GET_USERINSTALLED_NAMEARCH in solver.h

Install FindLibSolv.cmake -> /usr/<lib>/cmake/LibSolv/LibSolvConfig.cmake

The cmake module for LibSolv currently gets installed to

/usr/share/cmake/Modules/FindLibSolv.cmake

However, this breaks compliancy with cmake's packaging howto [1]. Package modules are not supposed to be installed into /usr/share/cmake[-<major.minor>]/.

The correct installation path and filename is:

/usr/lib/cmake/LibSolv/LibSolvConfig.cmake

Greets,
Mike

(also see: http://anonscm.debian.org/cgit/collab-maint/libsolv.git/commit/?id=669195bcf233f8b0a997770c18ff22c7cf3ba7be)

erase all deps flag

Hi, is in libsolv any solver flag that would allow to delete whole dependency tree of package marked for removal instead of installing new packages to satisfy broken deps? E.g.:

repo system 0 testtags <inline>
#>=Pkg: elinks 1 1 x86_64
#>=Prv: browser
#>=Pkg: xmlto 1 1 x86_64
#>=Req: browser
repo available 0 testtags <inline>
#>=Pkg: links 1 1 x86_64
#>=Prv: browser
system x86_64 rpm system
job erase name elinks
result transaction,problems <inline>
#>erase elinks-1-1.x86_64@system
#>erase xmlto-1-1.x86_64@system

I just wondering whether zypper supports that as it's common use case of yum users. If there's no such flag I can find all requires recursively and add them to erase job - I want to find the cleanest solution to solve that.

file conflicts multilib

Hello all,

As a fun test I compiled libzypp+zypper for Fedora 22
https://build.opensuse.org/project/show/home:damianator:fedora:zypper

On a vanilla Fedora 22 install I installed libzypp+zypper and did
zypper remove yum* dnf*

On Fedora the 32-bit lib packages are the 'normal' i686 packages of
the lib copied to the x86-64 repos.

So when you install a lib like alsa-lib.i686 it contains the same
files (the .so files reside in their respective /usr/lib or /usr/lib64
folders) the x86-64 version does.

For non binary files (which on both architectures are the same) no
conflict is there.

But alsa-lib (and other packages) contains also binaries like
'aserver' which differs for both architectures and zypper warns about
a file conflict and if I continue the
/usr/bin/aserver file from the x86-64 will be replaced with the one
from the i686 package, zypper says.

I was wondering why zypper warns about that and yum/dnf doesn't and
just installs the alsa-lib package.
Turns out even with zypper the file won't be replaced with the one
from the i686 package!
Explanation here:
https://lists.fedoraproject.org/pipermail/devel/2010-January/129725.html

When installed in parallel, multilib RPM packages may contain files that
live in common paths. When this happens, RPM uses the following algorithm:

• If the file in both packages is identical, installation is allowed
  and the file is written
• If the file in both packages is an ELF binary, the file used is the
  file in the package for the primary architecture
• If the file in both packages is not an ELF binary a RPM conflict is
  raised

So my suggestion here would be zypper also not to warn about a file conflict
if you're installing a package for a secondary architecture that
contains an elf file that conflicts with an elf file for your primary
architecture.
RPM heuristics will anyway not overwrite the elf file for you primary
architecture,
so zypper warning about that happening makes no sense (as it won't happen).

After discussion on libzypp-devel mailing list, we agreed that I open bug report @libsolv
http://lists.opensuse.org/zypp-devel/2015-07/msg00001.html

libsolv is installed from fedora repo http://fedora.c3sl.ufpr.br/linux/updates/22/SRPMS/l/libsolv-0.6.11-1.fc22.src.rpm

Internal ids in repo_lookup_idarray

Hello,

I am wondering whether the functions repo_lookup_idarray or lookup_idarray_solvable(repo.c) should not filter libsolv internal ids e. g. for SOLVABLE_REQUIRES I get ids: 15(solvable:prereqmarker), -2147483646(rpmlib(PayloadFilesHavePrefix)), ... . Is there any preferred way how to filter out those ids to obtain only "real" dependencies?

SAT solver competitions

Hi,

this is not an issue report, rather an invitation to communication with the Debian developer community.

Michael Tautschnig initated a discussion at [1] that you might want to give a statement on (via mail, use [2]). He is concerned about to many SAT solvers being around and not joining forces on that task.

Thanks+Greets,
Mike

[1] http://bugs.debian.org/761948
[2] [email protected]

Mark solvables as "not installed" in installed repo

In DEBIAN status file there might be packages that are half-installed (already unpacked but not yet configured). So after parsing status file and populating its content into installed repo, half-installed packages need to be marked as "not installed" since they have to be present in install transaction (if some package depends on them) for configuration.

RFE: add SOLVABLE_BUILD_REQUIRES

Hi,
I would like to sort packages by BuildRequires. While this task can be converted to Requires, it would be nice if libsolv can support SOLVABLE_BUILD_REQUIRES.

Multiversion packagers treated by evr substring

Hi,
Is possible to distinguish multiversion packages from evr in libsolv? Eg. Say we have java-1.8.0-openjdk and java-1.7.0-openjdk. These packages should be upgraded to the newest release of 1.7 and 1.8. So far the packages have the version in their name (java-1.8.0-openjdk-1.8.0.R.A) while packagers and users expect them to be named just java-openjdk. Ruby packages have similar issue.

We will have a meeting with java and ruby packagers and rpm guys to resolve this problem. We don't know yet how we should deal with them. I wanna do a research beforehand if it is possible in libsolv to deal with such cases when another rpm tag would be made. Have you tried to solve specific language packaging with different versioning, that doesn't fit to rpm package management, in SUSE too?

provide solver_describe_weakdep_decision via bindings

solver_describe_weakdep_decision is missing in solv.i so no binding generated for that