Ytdyklly

Given a random .DEB file, how do we check if installation will be successfully completed without actually installation on device? Please see the following snippet:

root@VirtualBox:/Folder# dpkg -i mysql-workbench_6.2.3+dfsg-7_armhf.deb 

Selecting previously unselected package mysql-workbench.

(Reading database ... 48937 files and directories currently installed.)

Preparing to unpack mysql-workbench_6.2.3+dfsg-7_armhf.deb ...

Unpacking mysql-workbench (6.2.3+dfsg-7) ...

dpkg: dependency problems prevent configuration of mysql-workbench:

 mysql-workbench depends on libatkmm-1.6-1 (>= 2.22.1); however:

  Package libatkmm-1.6-1 is not installed.

 mysql-workbench depends on libcairo2 (>= 1.14.0); however:

  Package libcairo2 is not installed.

 mysql-workbench depends on libcairomm-1.0-1 (>= 1.6.4); however:

  Package libcairomm-1.0-1 is not installed.

 mysql-workbench depends on libctemplate2; however:

  Package libctemplate2 is not installed.

 mysql-workbench depends on libgdal1h (>= 1.8.0); however:

  Package libgdal1h is not installed.

 mysql-workbench depends on libgdk-pixbuf2.0-0 (>= 2.22.0); however:

  Package libgdk-pixbuf2.0-0 is not installed.

 mysql-workbench depends on libgl1-mesa-glx | libgl1; however:

  Package libgl1-mesa-glx is not installed.

  Package libgl1 is not installed.

 mysql-workbench depends on libglibmm-2.4-1c2a (>= 2.42.0); however:

  Package libglibmm-2.4-1c2a is not installed.

 mysql-workbench depends on libgnome-keyring0 (>= 2.22.2); however:

  Package l

dpkg: error processing package mysql-workbench (--install):

 dependency problems - leaving unconfigured

Processing triggers for mime-support (3.58) ...

Processing triggers for shared-mime-info (1.3-1) ...

Errors were encountered while processing:

 mysql-workbench

root@VirtualBox:/Folder# echo $?

1

root@VirtualBox:/Folder# dpkg --dry-run -i mysql-workbench_6.2.3+dfsg-7_armhf.deb 

(Reading database ... 49115 files and directories currently installed.)

Preparing to unpack mysql-workbench_6.2.3+dfsg-7_armhf.deb ...

root@VirtualBox:/Folder# echo $?

0

root@VirtualBox:/Folder# dpkg --dry-run --simulate -i mysql-workbench_6.2.3+dfsg-7_armhf.deb 

(Reading database ... 49115 files and directories currently installed.)

Preparing to unpack mysql-workbench_6.2.3+dfsg-7_armhf.deb ...

root@VirtualBox:/Folder# echo $?

0

root@VirtualBox:/Folder# 

When I use the dpkg -i option, the command fails with a return value of 1, but the same command as a --dry-run returns zero. Adding the --simulate option also doesn't seem to change behaviour. Any pointers on how to consistently check if installation of a .DEB file will go through properly, without actually installing the package?

I am running this on a Raspberry Pi emulator.

root@VirtualBox:/Folder# cat /etc/os-release

PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"

NAME="Raspbian GNU/Linux"

VERSION_ID="8"

VERSION="8 (jessie)"

ID=raspbian

ID_LIKE=debian

HOME_URL="http://www.raspbian.org/"

SUPPORT_URL="http://www.raspbian.org/RaspbianForums"

BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

While this isn't technically an answer, it was a good question.

If we look at man dpkg, this is what it says about the options to test. If any real Debian experts can provide a more authoritative response, that would be good. Or edit mine if it has errors in it.

   --no-act, --dry-run, --simulate

          Do everything which is supposed to be done, but don't write any changes. This is used to see what would happen with the specified

          action, without actually modifying anything.

I believe, though I'm not certain, that in essence, all dpkg is testing is if the command has any flaws in it. For example, if you did:

#dpkg --dry-run -i nonexistent.deb || echo $?

dpkg: error: cannot access archive 'nonexistent.deb': No such file or directory

2

that's the result. One thing I noted was that dpkg required root even with --dry-run, it complained about not being able to use the log file, which means, --dry-run does not do at all what we expect. With apt-get, you can use --simulate as regular user.

dpkg is a very low level apt tool, and as you can see from its results in your tests, it did not know about the apt database and dependency trees until it actually installed the .deb file. So I would deduce that dpkg --dry-run or --simulate etc simply are testing the actual literal command data, not the dependencies etc.

Which suggests that while it appears to be the same command that works pretty decently, but not perfectly, in apt-get, it is in fact not at all the same. One would have to read the code in dpkg --simulate to see what it actually does.

Researching this issue appears to confirm what I believe is the case:

https://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013049.html

If a feature, is there an automatic way of checking a .deb's
dependencies, other than trying to dpkg -i it (and ending up
with under-configured packages) or doing a dpkg -f and checking
the dependencies one by one by hand?

What I'm looking for is a something like dpkg-buildpackage's
'Unmet build dependencies: ...' check, but for .debs.

There is a new application available called "gdebi" at:
http://people.ubuntu.com/~mvo/gdebi/

It should be able to resolve dependencies of deb package directly. It
contains gdebi-gtk and gdebi (and cli version). That might be what you
want. If not, please let me know and it may be added :) If you
use/test it, feedback (via private mail) is very much appreciated.

That's a very old thread, and I'm sure you're not looking for a gui tool, but it is worth noting that the issue existed in 2005 and someone crafted a gui solution that would check dependencies, which suggests that in fact, dpkg --simulate does not. Nor would I expect it to, I have done a lot of automated scripting for Debian apt, and dpkg, and the two act and behave very differently.

Various options to determine dependencies using dpkg

https://lists.debian.org/debian-user/2006/09/msg00292.html

That's an old Debian thread on the same question, again, you can see that dpkg --dry-run doesn't handle dependencies in general.

https://lists.debian.org/debian-user/2006/09/msg00297.html

dpkg-deb -I package.deb

Is the suggestion there. That shows basically the same thing as apt-cache show package-name.

So at least you can verify the dependencies yourself.

 dpkg -I perl_5.26.0-8_i386.deb

 ....

 Pre-Depends: dpkg (>= 1.17.17)

 Depends: perl-base (= 5.26.0-8), perl-modules-5.26 (>= 5.26.0-8), libperl5.26 (= 5.26.0-8)

....

https://lists.debian.org/debian-user/2006/09/msg00312.html

If you use dpkg --control pkg_file, then it will show you all of the
control information for the package, including dependencies.

I tested that, but it shows nothing, it may be obsolete, I don't know.

As you can see, Debian devs had several suggestions, but none of them suggested that there was a way to make dpgk --dry-run do what you want.

Conclusion

You have a few options, one, determine the dependencies manually, and this will certainly apply to your future case of creating your own debs, and then install those dependencies using a scripted install or whatever you find works for you, then install the .deb package after that.

Using the vm is a good option too, with snapshots, for testing.

To determine whether a package can be installed without needing other dependencies to be installed too, your best bet is to use the “simulate” mode with apt:

apt -s install ./mysql-workbench_6.2.3+dfsg-7_armhf.deb

(note the ./ which is significant). This will output the dpkg operations which would be performed by the real installation. Package installations are marked with Inst; if there’s more than one of these, the package can’t be installed on its own.

Now, on to the meaty part... You can’t use dpkg for this, not because dpkg doesn’t know about dependencies (it most definitely does), but because dependencies aren’t strong enough. When a package depends on another, the dependency doesn’t prevent the package from being installed if it’s not satisfied, it prevents it from being configured. See section 7.2 of Debian Policy:

A Depends field takes effect only when a package is to be configured. It does not prevent a package being on the system in an unconfigured state while its dependencies are unsatisfied, and it is possible to replace a package whose dependencies are satisfied and which is properly installed with a different version whose dependencies are not and cannot be satisfied; when this is done the depending package will be left unconfigured (since attempts to configure it will give errors) and will not function properly.

You can see this in your own test: the process fails with

dpkg: dependency problems prevent configuration of mysql-workbench

Note “configuration”, not “installation”. If you look at the output of dpkg -l mysql-workbench, you should see iU, which means the package is installed but not configured.

When you enable “simulate” mode in dpkg, it basically runs in read-only mode. It does this by setting a f_noact flag; you can look for this in the source code. When installing packages, simulation goes through the installation motions (without writing anything), and proceeds to the configuration phase; but that just fakes success, which is the only thing that a simulation can do — configuration involves running maintainer scripts in the package, and it would be difficult to ensure that those scripts didn’t make changes, or ensure that their success could be determined without allowing them to make changes. So in your case, the simulation installs the package, which succeeds (as in your non-simulated test), and fakes the configuration. Thus no error is detected...