Bugzilla – Bug 16166
sub_depends administration is not robust
Last modified: 2024-01-17 21:31:37 UTC
When setting up a new system I ran into the situation where cairo is installed, but does not have a bunch of optional dependencies enabled. When trying to cast gtk+3 it requests a number of sub dependencies on cairo which should trigger a cairo recast with the relevant optional dependencies enabled, but it didn't. Further investigation reveals that the PRE_SUB_DEPENDS file from tablet was not being run at all. Looking into sorcery code and examining the sorcery debug output I saw that libdepends checks /var/state/sorcery/sub_depends for "known" sub dependencies and as it turns out the gtk+3 to cairo sub dependencies are already recorded there without cairo ever having been built with the needed optional dependencies enabled! What I suspect is what happened, but have not yet confirmed, is that upon first trying to cast gtk+3 the PRE_SUB_DEPENDS was run, cairo was taking into the cast queue with the relevant optional dependencies enabled. At that time /var/state/sorcery/sub_depends was probably updated to reflect these sub dependencies, however somewhere during the complete cast process some spell failure led to cairo not actually being re-cast with the necessary optional dependencies enabled, yet /var/state/sorcery/sub_depends was not updated to reflect that the sub dependency was not satisfied. Note that this concerns a virgin install, at no time was there ever a gtk+3 on this system before and at no time was there ever a cairo with the relevant optional dependencies enabled. Also, I discovered this with sorcery test 1.16.0, but I am pretty sure that it also exists in previous sorcery releases.
After removing the offending lines from /var/state/sorcery/sub_depends and executing "cast gtk+3" the following happened: PRE_SUB_DEPENDS gets executed, re-cast of cairo gets triggered. 1. mesa build failure because of missing libepoxy apparently: * we have a circular dependency of gtk+3 -> libepoxy -> OPENGL(mesa) -> gtk+3 * mesa -> libepoxy is not even recorded in grimoire * libepoxy is a runtime dependency of mesa, but meson build is checking presence at build time... 2. cairo gets **resurrected** instead of re-cast 3. gtk+3 and libepoxy are dropped 4. gtk+3 to cairo sub dependencies are in /var/state/sorcery/sub_depends again even though gtk+3 was never cast and cairo was not cast with the necessary optional dependencies enabled
The /var/state/sorcery/sub_depends entry gets written even when one says no to the "Do you want to cast these spells?" prompt, so with current implementation it certainly cannot be relied upon to confer that the sub-dependency has already been met. 1st order solution is I think to remove this /var/state/sorcery/sub_depends checking using search_sub_depends from libdepends:real_sub_depends:1454-1459 This will cause the PRE_SUB_DEPENDS from tablet to always be run when a sub-depends is requested. It will probably slow down sorcery a little, but at least it'll be correct. After that we should probably completely check and revise the use of /var/state/sorcery/sub_depends