prefer native arch over higher priority for providers

The rational from the buglog:
> The problem here is that the Priority field in one of the Packages files
> is incorrect due to a mishap with reprepro configuration, […] the
> amd64 version is Priority: standard but the arm64 version is Priority:
> optional (and has a stray "optional: interpreters" field).
> […]
> However, Priority is a rather weak property of a package because it's
> typically applied via overrides, and it's easy for maintainers of
> third-party repositories to misconfigure them so that overrides aren't
> applied correctly.  It shouldn't be ranked ahead of choosing packages
> from the native architecture.  In this case, I have no user-mode
> emulation for arm64 set up, so choosing m4:arm64 simply won't work.

This effectly makes the priority the least interesting data point in
chosing a provider, which is in line with the other checks we have
already order above priority in the past and also has a certain appeal by
the soft irony it provides.

Closes: #718482

1 files changed, 3 insertions, 3 deletions

diff --git a/apt-pkg/depcache.cc b/apt-pkg/depcache.cc
index 9f8422fec..08c1bd809 100644
--- a/apt-pkg/depcache.cc
+++ b/apt-pkg/depcache.cc
@@ -1002,9 +1002,6 @@ struct CompareProviders {
 	 else if ((B->Flags & pkgCache::Flag::Important) == pkgCache::Flag::Important)
 	    return true;
       }
-      // higher priority seems like a good idea
-      if (AV->Priority != BV->Priority)
-	 return AV->Priority > BV->Priority;
       // prefer native architecture
       if (strcmp(A.Arch(), B.Arch()) != 0)
       {
@@ -1019,6 +1016,9 @@ struct CompareProviders {
 	    else if (*a == B.Arch())
 	       return true;
       }
+      // higher priority seems like a good idea
+      if (AV->Priority != BV->Priority)
+	 return AV->Priority > BV->Priority;
       // unable to decide…
       return A->ID < B->ID;
    }