A common thing that is growingly necessary is to manually resolve subslot conflicts. And its very exhausting waiting for portage to churn through the packages, only to find a problem, and there's presently no reliable machine readable way of getting this data in full comprehension of package dependency specifications. Ideally, in the long term, this feature request will escalate to a feature request for a more practical way to targetedly solve this problem directly through portage. But an interim solution that provides a machine readable list of problem package dependencies for a given CAT/PN:SLOT/SUBSLOT combination would be a significant stepping stone in the right direction. Please *dont* fall into the trap of thinking this is something that can be generalised as an "atom conflicts" tool, because that conflates too many different problem spaces. The only goal here is to ascertain that: 1. A given CAT/PN:SLOT/SUBSLOT is wanted to be installed 2. Packages that are already installed may conflict with this 3. Those packages should be enumerated as a list so they can be used. None of the existing tooling available answers this question reliably, due to either over-matching, or under-matching against atoms: - qdepends is regex based, so it requires additional glue to handle versions and USE constraints - equery depends is too lax, and matches anything that *loosely* matches a specification instead of tightly. Its output is also not useful for machine reading For instance: equery -C depends sys-libs/ncurses:0/5= Emits a vast supply of packages, even though *nothing* installed is actually built against ncurses 0/5 It also omits all subslot data from its output, leaving even secondary analysis useless: equery -NC depends sys-libs/ncurses:0/5= | grep libvirt # app-emulation/libvirt-3.0.0 (sys-libs/ncurses:0) qdepends -v -Q sys-libs/ncurses | grep 'ncurses:0/' | grep libvirt # app-emulation/libvirt-3.0.0: ... sys-libs/ncurses:0/6= ...
Its also important to note that none of this bug cares about the *contents* of the to-be-installed package. It doesn't even have to exist! Its just a question as to whether the VDB *would* allow a theoretical package of a given name:slot/subslot to be installed and what needs to change to make that happen.
