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
