[Aptitude-devel] Bug#758764: Bug#758764: Bug#758764: E: Internal error: couldn't generate list of packages to download

[David Kalnischkies]

On Thu, Aug 21, 2014 at 09:44:55AM +0200, Axel Beckert wrote:
> > 2014-08-21 13:10:45 upgrade imagemagick-doc:all 8:6.8.9.6-1 8:6.8.9.6-2
[…]
> > [UPGRADE] imagemagick-doc:i386 8:6.8.9.6-1 -> 8:6.8.9.6-2
> 
> The interesting thing here is as far as I can see that sometimes,
> imagemagick-doc seems an arch:all (dpkg.log) and sometimes an
> arch:i386 (aptitude's log) package. According to "apt-cache show" it's
> arch:all in both, Sid and Experimental.

This is very likely a red herring caused by internal organisation: If you
want to know if a package is arch:all, you have to ask the version for
the architecture (VerIterator), not the package (PkgIterator)!

This comes from the fact that an arch:all package is to be treated as an
arch:any package from the native architecture, so that the arch:all
packages will always be organized under packagename:nativearch – which
thankfully also makes upgrades a no-brainer. If we would organize them
"properly" a million little problems would creep up…

(This sounds very very silly as the word "package" is completely
overloaded here, but if you realize that a package can change from
arch:any to arch:all and back it becomes clear why this is a property of
the version and not of the package and why upgrades could become
problematic if it would be organized differently as it means we would
need to allow some inter-archs-upgrades and some not.)


Best regards

David Kalnischkies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20140828/af064d36/attachment.sig>