Hi Niko, On 20-07-18 13:24, Niko Tyni wrote: > Right, I was just thinking of fixing the worst bug where we currently > try to install both the alternatives rather than just one of them.
Sure. I was just not sure it that would be too easy. > Tracking which alternative dependency got installed by the first apt pass > (or was already installed before that, as in Samuel's case) is somewhat > hard for the case of Provides. The best I can come up with is something > like (for an example of perl Providing libtest-simple-perl): > > dpkg-query -W -f'${Status} ${Provides}\n' \* | grep -q '^install ok > .*libtest-simple-perl' && echo yes Haven't checked that command. But in most cases, there are no provides involved. Does that work for the regular depends (that is already installed). > which seems rather silly and not very well performing but probably works. Let's first focus on correctness, if possible, performance can be fixed later. > As for the rest of the implementation, we'd have to keep the list of > alternative dependencies around for longer, so that we still have the > information after running apt the first time. We can then run dpkg-query > and see if any one of the alternatives is installed as a real package. Right. It is something similar as I have in mind for the version check. Maybe we can combine those checks. https://salsa.debian.org/ci-team/autopkgtest/merge_requests/18 > If one is installed as a real package, there's no need for a separate apt > run for those packages. (Much of the same logic could probably also be > used to optimize away any unnecessary apt second pass runs that we're > currently doing.) right. > If none of the alternatives are installed as a real package, we'd have > to check which of them is provided by some other package, and only ask > for that in the second apt pass. > > Does that make sense? I think so. Paul
signature.asc
Description: OpenPGP digital signature