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 <r...@zigo.mirbsd.org> > > To: r...@zigo.mirbsd.org > > Date: Tue, 3 Apr 2012 06:25:41 GMT > > Subject: Cron <root@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org