New tool to check the dependency tree of your repos

eschwartz · 2018-09-02 02:41:16

levi wrote:

Thanks for the suggestions.
I couldn't get your fakerooted example to work as is, since the lock file genuinely needed root permissions to access. I was able to kind of getting it to work by specifying a local dbpath, but then it seemed to want to download the whole dependency tree for the package, which is rather unnecessary.

Local dbpath is fine, see how the "checkupdates" script from pacman-contrib does it though since you likel.

Or you could just use -dd to skip dependency checks, since you're operating as a download agent on a db copy...

But -Sp works. It does spit out the missing dependencies I think, but they seem to come first in the listing. I wasn't initially keen on just assuming the last entry is the right one, but I can also check it has the package name and the right version in it I guess, which seems like it should be reliable. Perhaps I don't even need to filter by position; just look for the thing with the right name and version, which I should already know, which should be less flakey in case pacman decides to reorder the output in the future.

This is actually an explicit feature, it should follow the same order as pacman -Su in listing the order of packages -- that is to say, IIRC it is topological dependency sorting.

We've actually received a bug report because someone wanted to have it alphabetically sorted or sorted by command-line order.
https://bugs.archlinux.org/task/59371

But again, -Sddp would only print the packages you explicitly list, without also listing the unfulfilled dependencies you'd need to install first.

eschwartz · 2018-09-02 02:53:29

levi wrote:

So the list is really:
make (core) -> guile (extra)
python-gpgme (core) -> python (extra) (ditto for python2)
qgpgme (core) -> qt5-base (extra)
squlite-analyzer (core) -> tcl (extra)
util-linux (core) -> libcap-ng (extra)
I guess, to fix those things either need to be pushed from core back out to extra (python-gpgme maybe) or vice versa and promoted (libcap-ng perhaps), or a third way which is to demote the positive dependency down to an optional dependency (I don't see why make can't work without guile).
For anyone else, I'll try to make clear that these issues have only been tested on arch64 so far, but I reckon there's good odds these apply in arch32 too. They should probably be fixed upstream and ported down though I guess.

Huhhhhhh. I'll need to raise this for discussion.

Make is linked to guile, in order to support the guile scripting language in make. Seems to me like guile should be in core.

python-gpgme and qgpgme are split packages not really needed for gpgme, but they're in core because their split pkgbase is... maybe we could fix that, maybe they should just be one package with optdepends.
Same logic applies for sqlite-analyzer

util-linux depends on libcap-ng for /usr/bin/setpriv, added in https://bugs.archlinux.org/task/53248 but I think libcap-ng should have been moved to core at the time...

I suppose, though, that all things being considered core is still doing pretty good in this respect, with the exception of a few things that just sneaked in.

We used to have a service to report on things like this, but it died for a few reasons including https://www.archlinux.org/news/deprecation-of-abs/

levi · 2018-09-02 22:18:49

Ah, thanks for the hint about -dd; I must have missed where it says that in man pacman. Using -Sddp and then constructing a curl statement based on the returned string seems easier than having to set up some fake directories to get fakerooted -Sddw to work, and then I can check the contents using tar -tf while redirecting STDERR to /dev/null since there seems to be some metadata tar doesn't understand which it squarks about before every line; unless there's a simpler way of listing the package contents without installing it?

And yeah, I don't think that handful of packages that can't be installed with core only is bad given the couple hundred that are in that repo. It just surprised me that there were any.

Currently in my refactoring, I've hit a situation where I have versioned and unversioned package names swimming in front of me. I may need to sleep on this to get my head round it.

eschwartz · 2018-09-03 05:28:45

levi wrote:

Ah, thanks for the hint about -dd; I must have missed where it says that in man pacman. Using -Sddp and then constructing a curl statement based on the returned string seems easier than having to set up some fake directories to get fakerooted -Sddw to work, and then I can check the contents using tar -tf while redirecting STDERR to /dev/null since there seems to be some metadata tar doesn't understand which it squarks about before every line; unless there's a simpler way of listing the package contents without installing it?

Use bsdtar instead of tar.

Actually, many people will tell you that that is a general lesson for life.

levi · 2020-06-26 22:01:52

So, I brought this out of retirement in case it could help me with the current perl problem, but to begin with I just undid some of my recent experimentation and got it running again. It currently tells me:

21:19$ ./archrepocheck 
ERROR: Couldn't satisfy dependency isdn4k-utils of package archboot 2018.06-3.1
ERROR: Couldn't satisfy dependency librpcsecgss of package archboot 2018.06-3.1
ERROR: Couldn't satisfy dependency idnkit of package archboot 2018.06-3.1
ERROR: Couldn't satisfy dependency isdn4k-utils of package capi4hylafax 010300-11.6
Warning: Optional dependency libcbor.so at version 0.7-32 is asked to be =0-32 by package libfido2 1.4.0-1.0
ERROR: Couldn't satisfy dependency isdn4k-utils of package misdnuser 2.0.22-2.2
ERROR: Couldn't satisfy dependency electron of package caprine 2.18.0-1.0
Warning: Couldn't satisfy optional dependency dbeaver of package dbeaver-plugin-apache-poi 3.16.0-3.0
Warning: Couldn't satisfy optional dependency dbeaver of package dbeaver-plugin-batik 1.9.1-4.0
Warning: Couldn't satisfy optional dependency dbeaver of package dbeaver-plugin-bouncycastle 1.61.0.v20190602.1335-1.0
Warning: Couldn't satisfy optional dependency dbeaver of package dbeaver-plugin-office 1.1.53.201908191349-1.0
Warning: Couldn't satisfy optional dependency dbeaver of package dbeaver-plugin-svg-format 1.0.51.201908191349-1.0
ERROR: Couldn't satisfy dependency electron of package geogebra 6.0.487.0-1.0
ERROR: Couldn't satisfy dependency openvas-libraries of package greenbone-security-assistant 7.0.3-1.3
Warning: Optional dependency perl at version 5.32.0-1.0 is asked to be <5.31 by package hivex 1.3.18-6.0
ERROR: Couldn't satisfy dependency electron of package keybase-gui 2.6.2-1.0
ERROR: Couldn't satisfy dependency electron of package min 1.7.1-1.0
ERROR: Couldn't satisfy dependency python2-openstacksdk of package python2-os-client-config 1.32.0-1.1
ERROR: Couldn't satisfy dependency python2-sip of package python2-qtconsole 4.5.5-1.0
Warning: Optional dependency xapian-core at version 1:1.4.16-1.0 is asked to be =1:1.4.15 by package python2-xapian 1:1.4.15-1.0
ERROR: Couldn't satisfy dependency electron of package react-native-debugger 0.9.13-1.0
ERROR: Couldn't satisfy dependency electron of package riot-desktop 0.14.2-1.0
Warning: Optional dependency libjsoncpp.so at version 22-32 is asked to be =21-32 by package sysdig 0.26.4-4.1

Looks like electron isn't being built for arch32 any more. We could get rid of those electron depending packages as well to avoid confusing the users, if that was really what was intended. It does point to hivex being a real perl problem, and I've not looked into any of the other problems yet.

Arch Linux

#26 2018-09-02 02:41:16

Re: New tool to check the dependency tree of your repos

#27 2018-09-02 02:53:29

Re: New tool to check the dependency tree of your repos

#28 2018-09-02 22:18:49

Re: New tool to check the dependency tree of your repos

#29 2018-09-03 05:28:45

Re: New tool to check the dependency tree of your repos

#30 2020-06-26 22:01:52

Re: New tool to check the dependency tree of your repos

Board footer