pactree incorrectly resolves versioned dependency into provider

dervish · 2018-06-15 11:53:12

Hello everyone!
I noticed that 'pactree' produces different results for local and sync databases:

$ pactree -u gptfdisk | wc -l
41
$ pactree -su gptfdisk | wc -l
10

Therefore, 'pactree' builds different dependency trees for 'gptfdisk' package.
I synchronized and updated the system 'pacman-Syyu' but the difference did not disappear.

$ pactree -d1 gptfdisk
gptfdisk
├─gcc-libs
├─popt
├─lib32-util-linux provides libuuid.so   <---difference
└─ncurses provides libncursesw.so

$ pactree -sd1 gptfdisk
gptfdisk
├─gcc-libs
├─popt
├─libutil-linux provides libuuid.so      <---difference
└─ncurses provides libncursesw.so

'pactree' substitutes different package-providers for 'libuuid.so'.

Let's see 'pacman' details:

$ pacman -Qi gptfdisk | grep Depends
Depends On      : gcc-libs  popt  libuuid.so=1-64  libncursesw.so=6-64
                                  ^^^^^^^^^^^^^^^

$ pacman -Q libuuid.so=1-64
libutil-linux 2.32-3           <---correct

$ pacman -Q libuuid.so
lib32-util-linux 2.32-1        <---WHY?!

The right thing to do is to use 'libutil-linux' for 'gptfdisk'.

What is happening and how to fix the situation?

Last edited by dervish (2018-06-21 04:17:57)

Trilby · 2018-06-15 12:06:04

dervish wrote:

'pactree' substitutes different package-providers for 'libuuid.so'.

No, you did that. You installed the multilib version of a package which also provides libuuid.so.

EDIT: ah, but it does appear pactree is not properly using versioned dependencies in your output. If gptfdisk just dependended on libuuid.so, then the output you get could be expected. The default provider of libuuid.so in the repos would be libutil-linux, but on your system you have the lib32 version too. But is gptfdisk has a versioned depedency, only the former satisfies the requirement, but pactree may be ignoring versions of versioned dependencies.

Last edited by Trilby (2018-06-15 12:13:47)

dervish · 2018-06-15 12:29:27

Trilby wrote:

No, you did that. You installed the multilib version of a package which also provides libuuid.so.

Thanks for the reply.
Yes, I think 'wine' requires 'lib32-util-linux'.

pacman -Qi lib32-util-linux | grep Provides
Provides    : libuuid.so=1-32  libblkid.so=1-32  libfdisk.so=1-32  libmount.so=1-32  libsmartcols.so=1-32
              ^^^^^^^^^^^^^^^
pacman -Qi libutil-linux | grep Provides
Provides    : libblkid.so=1-64  libfdisk.so=1-64  libmount.so=1-64  libsmartcols.so=1-64  libuuid.so=1-64
              ^^^^^^^^^^^^^^^^

But the package 'gptfdisk' explicitly depends on the version of 'libuuid.so=1-64' as I wrote above.
Why 'pactree' and 'pacman' shows provider 'libutil-linux'.
And why the results of 'pactree' differ with '-s' key and without.

Trilby · 2018-06-15 12:35:21

dervish wrote:

Why 'pactree' and 'pacman' shows provider 'libutil-linux'.

Pacman doesn't, as you posted in your first post, pacman gets it right: if you give it the versioned dependency it lists libutil-linux as the package that provides it. If you give it an unversioned dependency, pacman says lib32util-linux satisfies that dependency which is also correct.

Pactree just seems to ignore the version of the dependency. This may be a bug with pactree though at the moment this is just a hypohtesis based on one observation.

dervish wrote:

And why the results of 'pactree' differ with '-s' key and without.

In many cases this could be expected. There are often many packages which could fulfill a dependency. Without the -s flag, pactree will check the local database (of installed packages) for something that satisfies the dependency. With the -s flag, it will check the repos for anything that satisfies the dependency. It's not surprising at all that these could come up with different options and be perfectly legitimate. In the present case, it does not seem legitimate, but again, this could just be due to pactree not handling versioned deps.

Perhaps a revision to your title will draw in the right people to see this if you highlight the suspicion that pactree is ignoring versioned dependencies.

Last edited by Trilby (2018-06-15 12:37:49)

dervish · 2018-06-15 13:05:56

Trilby wrote:

Pactree just seems to ignore the version of the dependency. This may be a bug with pactree though at the moment this is just a hypohtesis based on one observation.

Thanks a lot. I think you're right. The system works fine.
And pacman gets it right with the versioned dependency, but pactree - I'm not sure.
When I manually investigate '/var/lib/pacman/ local/', all dependencies are resolved correctly as I see.

dervish · 2018-06-16 09:58:57

Hello everyone!

To submit a report for a bug tracker I need to understand whether there is a similar discrepancy on other systems.

I wrote a script that compares the output of 'pactree' for all installed packages.
If you have time, run it and share the results.
NB 'pacman-contrib' and 'expac' packages are required.

#!/bin/bash
for pkg in $(expac '%n %D' $(pacman -Qnq) | awk '/[=<>]/ { print $1 }'); do
    cmp -s <(pactree -sld1 $pkg) <(pactree -ld1 $pkg) ||
       { echo "$pkg :  pactree outputs different results";
         error=True; }
done
if [[ $error ]]; then
    echo "You can check the results by manually comparing the commands:"
    echo "pactree -sd1 <package>  and  pactree -d1 <package>"
else
    echo "No errors found."
fi

An example of my system research.

Save and run the script.

$ ./pactree-test
gptfdisk :  pactree outputs different results

You can check the results by manually comparing the commands:
pactree -sd1 gptfdisk and pactree -d1 gptfdisk

As we can see for package gptfdisk 'pactree' resolves different package-providers for libuuid.so

$ diff <(pactree -sd1 gptfdisk) <(pactree -d1 gptfdisk)
< ├─libutil-linux provides libuuid.so
    ^^^^^^^^^^^^^
> ├─lib32-util-linux provides libuuid.so
    ^^^^^^^^^^^^^^^^

What version of the package does 'gptfdisk' need?

$ pacman -Qi gptfdisk | grep Depends
Depends On: gcc-libs  popt  libuuid.so=1-64  libncursesw.so=6-64
                            ^^^^^^^^^^^^^^^

The package 'libuuid.so' is absent but there are two providers:

$ pacman -Qi libutil-linux | grep Provides
Provides: libuuid.so=1-64 libblkid.so=1-64  libfdisk.so=1-64  libmount.so=1-64  libsmartcols.so=1-64
          ^^^^^^^^^^^^^^^
$ pacman -Qi lib32-util-linux | grep Provides
Provides: libuuid.so=1-32  libblkid.so=1-32  libfdisk.so=1-32  libmount.so=1-32  libsmartcols.so=1-32
          ^^^^^^^^^^^^^^^

When traversing the 'gptfdisk's dependency tree 'pactree' should use 'libutil-linux'. And it finds it by explicitly specifying the version. But without version it chooses lib32-util-linux.

$ pactree -d0 libuuid.so=1-64
libutil-linux provides libuuid.so=1-64

$ pactree -d0 libuuid.so
lib32-util-linux provides libuuid.so

Just like 'pacman' by the way!

$ pacman -Q libuuid.so
lib32-util-linux 2.32-1

Do you have similar issues?

Last edited by dervish (2018-06-16 19:18:16)

Trilby · 2018-06-16 11:52:12

Thanks for writing a script to try to test this. I have no such issues here. But I suggest a cleaner approach to the test, rather than comparing (byte by byte) the pactree outputs, just look for cases where pactree *could* have a problem: packages with versioned dependencies given by expac:

expac '%n %D' | awk '/[=<>]/ { print $1; }'

Then from that list you can compare the output of `pacman -Qi $pkg` with `pactree -ld1 $pkg` and you will see versions for versioned deps are never listed in pactree.

The question then is whether pactree simply does not display the version, or if it doesn't use it in finding dependencies. That will only likely be apparent in cases where one has a different package installed than what the default package to satisfy that dependency is.

It seems the absence of versions in pactree output is common (30 packages on my system), but as I have the default dependencies for all 30 of those packages, the pactree and pactree -s output are the same.

If there is a bug here, I think it's really much simpler than your script makes it: if pactree ignores versioned deps than it can lead to incorrect output as your gptfdisk example shows. The only test I'd want to see is whether there is something odd about the state of your system, or if other users of gptfdisk who also have lib32-util-linux from multilib also see this discrepancy.

dervish · 2018-06-16 12:53:38

I didn't think about the 'expac' - thanks, Trilby!
So much faster. Fixed the script.
And then I'll reread your post again and think about it;)

CarbonChauvinist · 2018-06-16 13:26:48

$ pactree-test.sh 
error: package 'auracle-git' not found
auracle-git :  pactree outputs different results
error: package 'aurutils' not found
aurutils :  pactree outputs different results
ffmpeg :  pactree outputs different results
error: package 'gksu' not found
gksu :  pactree outputs different results
gptfdisk :  pactree outputs different results
error: package 'trizen' not found
trizen :  pactree outputs different results
error: package 'yay' not found
yay :  pactree outputs different results
You can check the results by manually comparing the commands:
pactree -sd1 <package>  and  pactree -d1 <package>

$ pacman -Ss lib32-util-linux
multilib/lib32-util-linux 2.32-1 [installed]
    Miscellaneous system utilities for Linux (32-bit)

$ pactree -sd1 gptfdisk
gptfdisk
├─gcc-libs
├─popt
├─libutil-linux provides libuuid.so
└─ncurses provides libncursesw.so

$ pactree -d1 gptfdisk
gptfdisk
├─gcc-libs
├─popt
├─lib32-util-linux provides libuuid.so
└─ncurses provides libncursesw.so

Last edited by CarbonChauvinist (2018-06-16 13:28:06)

dervish · 2018-06-16 13:38:38

Thanks, CarbonChauvinist.
You have the same result with 'gptfdisk'.
I did not have time to correct the script a little more. All packages except 'gptfdisk' are not in sync db, so don't pay attention to them.

Trilby · 2018-06-16 16:00:02

CarbonChauvinist's results indicate this is not a quirk of your system - so it seems reasonable to me to bring it up on the bug tracker.

CarbonChauvinist · 2018-06-16 17:32:38

Not sure if the following is helpful, superfluous, or noise, but I have the same behavior with ffmpeg (notice the difference between lib32-libvorbis, lib32-libvpx1.3 and libvorbis, libvpx in the pactree output)

$ pacman -Ss ffmpeg
extra/ffmpeg 1:4.0-3 [installed]
    Complete solution to record, convert and stream audio and video

$ diff <(pactree -sd1 ffmpeg) <(pactree -d1 ffmpeg)
43,45c43,45
< ├─libvorbis provides libvorbisenc.so
< ├─libvorbis provides libvorbis.so
< ├─libvpx provides libvpx.so
---
> ├─lib32-libvorbis provides libvorbisenc.so
> ├─lib32-libvorbis provides libvorbis.so
> ├─lib32-libvpx1.3 provides libvpx.so

pacman -Qi ffmpeg | ag Depends
Depends On      : alsa-lib  bzip2  fontconfig  fribidi  glibc  gmp  gnutls  gsm  lame  libavc1394  libdrm  libiec61883  libmodplug  libomxil-bellagio  libpulse  libraw1394  libsoxr  libssh  libtheora  libvdpau  libwebp  libx11  libxcb  libxext  libxml2  libxv  opencore-amr  openjpeg2  opus  sdl2  speex  v4l-utils  xz  zlib  libass.so=9-64  libbluray.so=2-64  libfreetype.so=6-64  libva-drm.so=2-64  libva.so=2-64  libva-x11.so=2-64  libvidstab.so=1.1-64  libvorbisenc.so=2-64  libvorbis.so=0-64  libvpx.so=5-64  libx264.so=152-64  libx265.so=160-64  libxvidcore.so=4-64

Edited to use @Dervish's tip for shortened output of pactree comparison

Last edited by CarbonChauvinist (2018-06-16 22:22:12)

dervish · 2018-06-16 18:08:25

CarbonChauvinist wrote:

Not sure if the following is helpful, superfluous, or noise, but I have the same behavior with ffmpeg (notice the difference between lib32-libvorbis, lib32-libvpx1.3 and libvorbis, libvpx in the pactree output)

Yes, it's the same issue. You can shorten the output:

diff <(pactree -sd1 ffmpeg) <(pactree -d1 ffmpeg)

You've got two 32-bit packages: lib32-libvorbis, lib32-libvpx1.3.
My system does not have them so I have no this discrepancy with 'ffmpeg'.

Last edited by dervish (2018-06-16 18:12:40)

dervish · 2018-06-21 04:19:37

After reporting the bug the error has been fixed:
https://bugs.archlinux.org/task/59072?opened=28100
Thanks, Johannes Löthberg!
Nice and fast work!

Versions of dependecies are correctly resolved and printed!

pactree -d1 gptfdisk
gptfdisk
├─gcc-libs
├─popt
├─libutil-linux provides libuuid.so=1-64
└─ncurses provides libncursesw.so=6-64

I think if this patch comes with a new release the issue will be solved.
Thanks for the help, Trilby, CarbonChauvinist!

Last edited by dervish (2018-06-21 04:26:37)

Trilby · 2018-06-21 11:40:55

Great. Thanks for reporting the bug. Please remember to mark this thread as [SOLVED] by editing your first post.

dervish · 2018-06-21 12:00:16

Trilby wrote:

Please remember to mark this thread as [SOLVED] by editing your first post.

Sure. I will do it when the package 'pacman-contrib' is updated.

Arch Linux

#1 2018-06-15 11:53:12

pactree incorrectly resolves versioned dependency into provider

#2 2018-06-15 12:06:04

Re: pactree incorrectly resolves versioned dependency into provider

#3 2018-06-15 12:29:27

Re: pactree incorrectly resolves versioned dependency into provider

#4 2018-06-15 12:35:21

Re: pactree incorrectly resolves versioned dependency into provider

#5 2018-06-15 13:05:56

Re: pactree incorrectly resolves versioned dependency into provider

#6 2018-06-16 09:58:57

Re: pactree incorrectly resolves versioned dependency into provider

#7 2018-06-16 11:52:12

Re: pactree incorrectly resolves versioned dependency into provider

#8 2018-06-16 12:53:38

Re: pactree incorrectly resolves versioned dependency into provider

#9 2018-06-16 13:26:48

Re: pactree incorrectly resolves versioned dependency into provider

#10 2018-06-16 13:38:38

Re: pactree incorrectly resolves versioned dependency into provider

#11 2018-06-16 16:00:02

Re: pactree incorrectly resolves versioned dependency into provider

#12 2018-06-16 17:32:38

Re: pactree incorrectly resolves versioned dependency into provider

#13 2018-06-16 18:08:25

Re: pactree incorrectly resolves versioned dependency into provider

#14 2018-06-21 04:19:37

Re: pactree incorrectly resolves versioned dependency into provider

#15 2018-06-21 11:40:55

Re: pactree incorrectly resolves versioned dependency into provider

#16 2018-06-21 12:00:16

Re: pactree incorrectly resolves versioned dependency into provider

Board footer