Comment 2 for bug 909885

I have tracked this down a bit and here's what I believe is happening:
  software-center creates a DebPackage object (in /usr/share/software-center/softwarecenter/db/debfile.py)
    DebPackage.__init__() (from /usr/share/pyshared/apt/debfile.py) calls
      DebPackage.open() which calls
        apt_inst.DebFile which is implemented in libapt-inst.so by apt-inst/deb/debfile.cc from the apt package
          which creates an AR object implemented in apt-inst/contrib/arfile.cc
            which calls ARArchive::LoadHeaders()
              which calls StrToNum(Head.Size,Memb->Size,sizeof(Head.Size))

I have confirmed with traces that we get a Python exception during the execution of the apt_inst.DebFile constructor. The full text of the exception is:

E:Could not open file /home/weaver/testpkg_1.0-1_all.deb - open (75: Value too large for defined data type), E:Unable to determine the file size - fstat (9: Bad file descriptor), E:Read error - read (9: Bad file descriptor)

I have not confirmed where the problem occurs in the lower levels though, they may happen in the File() constructor.

StrToNum() returns an unsigned long so on 32bit platforms it definitely cannot deal with package sizes between 4GiB and 10GB (which the ar file format can deal with). We find a similar issue with ARArchive::Member.Size. So there's apparently no support for large files on 32bit platforms.

However we get an error with 2GiB already on 32bit platforms. The first thing ARArchive::LoadHeaders() does is:

   signed long Left = File.Size();

On 32bit platforms that's a signed 32bit quantity and will thus end up being negative for a 2.4GiB package, then shunting 'while (Left > 0)' so we won't find the control and data members of the archive. This in turn will cause the DebFile() constructor to return an error when CheckMember("control.tar.gz") returns False.

Unfortunately that's likely just the tip of the iceberg.