[Popcon-developers] Bug#660712: popularity-contest broken with Multi-Arsch

[Guillem Jover]

On Tue, 2012-04-03 at 20:29:46 +0200, Bill Allombert wrote:
> On Tue, Apr 03, 2012 at 03:27:47PM +0000, Thorsten Glaser wrote:
> > From: Cron Daemon <root at zigo.mirbsd.org>
> > To: root at zigo.mirbsd.org
> > Date: Tue, 3 Apr 2012 06:25:41 GMT
> > Subject: Cron <root at zigo> test -x /usr/sbin/anacron || ( cd / && run-parts
> >     --report /etc/cron.daily )
> > 
> > /etc/cron.daily/popularity-contest:
> > dpkg-query: error: --listfiles needs a valid package name but 'gcc-4.7-base' is not: ambiguous package name 'gcc-4.7-base' with more than one installed instance
> 
> I think dpkg should just report the list of files in both packages to
> preserve the API.

The API is preserved as long as no multiarch is enabled. With
multiarch enabled any sane behaviour implies an interface change.
Outputting multiple paragraphs per package set would imply you need
to know which paragraph belongs to which package instance, it would
also produce duped content because you'd be requesting multiple times
the list for a package set for each instance present.

So, in the popularity-contest case, the program IMO needs to be adapted
anyway to support multiarch natively, as it stands currently (AFAICS),
the information submitted will not be accurate, as there's only a
single global architecture (the one from dpkg), but this is not really
representative of what the system is capable of (what the kernel can
run) or which architecture each package got installed for. dpkg has
always supported foreign architecture packages (although through a
force option), but with multiarch this is going to be even more
widespread.

There's also the cross-grading and mixed architectures case, where that
global architecture might be pretty meaningless, consider a system where
almost all packages are for amd64 but dpkg itself is for i386, or one
where packages are half-half different architectures, or even one where
the dpkg architecture differs from apt's architecture for example. I
think it's more relevant to know what the kernel can run, for example if
dpkg is i386 but the kernel is amd64, where the latter seems more
meaningful to me than the former.

So I'd say popcon needs to track the architecture for every and each
package instance, at which point requesting the specific information
for each package architecture instance should be pretty easy.

thanks,
guillem