3

There is a .deb package in a repository which is declared to be 32bit, but installs 64bit binaries. This is the case for both installing through apt-get from the repository as well as with downloading the .deb file and running dpkg -i.

If I install the file to try, it upgrades/overwrites my existing application in 32bit, and I can't run it any more (on 15.04 32bit Ubuntu). When this happened first, I searched the installed executable with which and checked it's type with file, that proved it to be a 64bit ELF binary:

$ file qtox
qtox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, stripped

So while I wait for the maintainers to fix the issue, how can I determine which architecture a package (from repository or .deb file) contains?

I tried both apt-cache show and apt-cache policy for the repository version and dpkg -I for the .deb file, but all of them report 32bit, which is wrong.

Is there any chance to find the real architecture the contained executables are made for out, except by accessing the package's meta information (I think this is what the commands I tried did?) which does obviously not fit.

Byte Commander
  • 107,489

3 Answers3

5

Create a script, in my example foo

#!/bin/bash

# Create a temporary folder in /tmp
dir=$(mktemp -d)

# Extract the deb file
dpkg -x "$1" "$dir"

printf "\n%s\n\n" "$1"

# Show the package architecture information
dpkg --info $1 | \
    awk '/Architecture/ {printf "defined dpkg architecture is:\t%s\n", $2}'

# Show the executable format via find and awk for ELF
find $dir -type f -exec file -b {} \; | \
        sort -u | \
        awk '/ELF/ {printf "executable format is: \t\t%s\n", $0}'

rm -rf "$dir"

exit 0

Usage

./foo <deb_file>

Example

% ./foo qtox_1.1\~git20150707.cfeeb03-97_i386.deb

qtox_1.1~git20150707.cfeeb03-97_i386.deb

defined dpkg architecture is:   i386
executable format is :          ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, stripped
muru
  • 197,895
  • 55
  • 485
  • 740
A.B.
  • 90,397
1

A DEB package is just an archive with very specific contents. You can open it in any archive manager you like (such as File Roller or whatever) and the contents are laid out as if you empty it into /. All you need to do is locate a binary and query its file type. This isn't usually necessary - if the filename has i386 in it, it should be i386. Your case is definitely abnormal, so I'm wondering how the package maintainers let that happen.

  • It worked. I opened the .deb file with my archive manager, navigated to /usr/bin inside the archive and extracted the qtox binary. Running the file command on it produced the known 64bit description. Could you automate this procedure a bit if the binary's location inside the file is known now? A little script that automatically opens the archive, extracts the binary to e.g. my home or any temporary directory, prints its file output and deletes it again would be the best possible answer. – Byte Commander Aug 13 '15 at 10:14
-1

Each deb package declares an architecture, eg. "i386" or "all". However this is only a declaration, and it can be declared wrong (intentionally for some reason, or eg. by error in some package building script).

What can you about to verify the real package architecture:

# verify, if package supports multiple architectures (and possibly has some bug):
dpkg --print-foreign-architectures package.deb

# unpack and check executables inside:
dpkg --unpack package.deb
dpkg --contents package.deb |grep ^-rwxr-xr-x |awk "{ print \$6 }" |grep -v /etc/

# and then check a few random unpacked executables using:
file ./usr/bin/some-executable
  • Wait, does this unpack package content into /usr/bin/??? I don't want it to be spread out there, especially to prevent it from overwriting my current installation of the latest available real 32bit version. And I want to get rid of all those files after verifying, so please make sure it all stays inside one temporary folder I can easily nuke later. – Byte Commander Aug 13 '15 at 09:58
  • dpkg: error: --print-foreign-architectures takes no arguments – A.B. Aug 13 '15 at 10:07
  • dpkg --unpack package.deb gives dpkg: error: requested operation requires superuser privileg – A.B. Aug 13 '15 at 10:09
  • 1
    @A.B. the answer comes close. You can extract to your current directory using dpkg-deb: dpkg-deb --fsys-tarfile | tar x ./usr/bin. Then you can do: file ./usr/bin/qtox – muru Aug 13 '15 at 10:59
  • dpkg --unpack extracts files to current directory, not to root directory. – Tomasz Klim Aug 13 '15 at 13:21