Recently I happened to reinstall my Ubuntu in to Lubuntu 15.04. So I was searching for Skype installation and got this nice tutorial.

It was really cool. It downloaded official package of skype deb from here

Since I don't have gdebi already installed, I installed using sudo su -c apt-get install gdebi

Then installed skype-ubuntu-precise_4.3.0.37-1_i386.deb by using gdebi command sudo su -c gdebi skype-ubuntu*4*.deb

Wow, gdebi did everything for me, what a hassle free thing without using traditional Apt PPA manual links addition which will probably breaking my system updates/software installations as well ..

But if I try to install it using dpkg -i

dpkg -i skype-ubuntu-precise_4.3.0.37-1_i386.deb
Selecting previously unselected package skype.
(Reading database ... 86449 files and directories currently installed.)
Preparing to unpack skype-ubuntu-precise_4.3.0.37-1_i386.deb ...
Unpacking skype (4.3.0.37-1) ...
dpkg: dependency problems prevent configuration of skype:
 skype depends on libc6 (>= 2.3.6-6~).
 skype depends on libc6 (>= 2.7).
 skype depends on libgcc1 (>= 1:4.1.1).
 skype depends on libqt4-dbus (>= 4:4.5.3).
 skype depends on libqt4-network (>= 4:4.8.0).
 skype depends on libqt4-xml (>= 4:4.5.3).
 skype depends on libqtcore4 (>= 4:4.7.0~beta1).
 skype depends on libqtgui4 (>= 4:4.8.0).
 skype depends on libqtwebkit4 (>= 2.2~2011week36).
 skype depends on libstdc++6 (>= 4.2.1).
 skype depends on libx11-6.
 skype depends on libxext6.
 skype depends on libxss1.
 skype depends on libxv1.
 skype depends on libssl1.0.0.
 skype depends on libpulse0.
 skype depends on libasound2-plugins.

dpkg: error processing package skype (--install):
 dependency problems - leaving unconfigured
Processing triggers for hicolor-icon-theme (0.13-1) ...
Processing triggers for mime-support (3.55ubuntu1.1) ...
Processing triggers for desktop-file-utils (0.22-1ubuntu2) ...
Processing triggers for dbus (1.8.8-1ubuntu2.1) ...
Errors were encountered while processing:
 skype

So much of dependencies issues . Oh I just googled GDebi and wikipedia has

GDebi is an APT tool which can be used in command-line and on the GUI.[44] GDebi can install a local .deb file via the command line like the dpkg command, but with access to repositories to resolve dependencies

My wonder is

(1) How does gdebi install .deb Packages with Dependencies without using Apt PPA links added manually in configuration files?

(2) Can I use same gdebi command ( sudo su -c gdebi my.deb )to install all other .deb packages without adding Apt PPA or do I have to change the format like so: sudo su -c my*n*.deb where n is version of software, etc?

Please explain in layman terms so that I can get it.

up vote 7 down vote accepted

Actually gdebi is just a front-end to the dpkg with added functionality that it can check for dependency packages in the repositories and can install them in one-operation, while dpkg -i requires two operations manually (later being apt-get -f install).

Question 1:

1) How gdebi do this? install .deb Packages with Dependencies without using Apt PPA links added manually in configuration files?

Being a dpkg front-end, it can use all of the functionality of dpkg. Since every .deb package file contains (provided that they are not corrupt) metadata about that deb file (like package name, maintainer, dependencies etc), it can easily check this file's dependency.

For example, you can check a .deb file's metadata using dpkg --info package-name.deb

And then it uses these information to construct dependency map and mark the locally available .deb files as already downloaded and download other .deb files from Internet.

Take note that, those needed extra packages must be available (with proper version) in at least one of the repositories, which are configured in the system.

Then it proceed to like a normal apt installation. The difference is it doesn't re-download the main .deb file

Question 2:

(2) Can I use same gdebi command ( sudo su -c gdebi my.deb )to install all other deb packages without adding a PPA? or do I have to change format sudo su -c myn.deb where n is version of software etc?

The PPAs exists for a reason. The main reason is they provide latest versions of packages . And these higher versioned package usually depends on higher versions of sub-packages also, which are also normally served from the PPA, not from standard Ubuntu repository.

Example Scenario:

Suppose, A package named mother-package has the highest version of 2.0 in Standard Ubuntu repositories, and this mother-package depends on a package named child-package of version 2. Also suppose, some PPA provides mother-package of version 3.0 which requires on child-package of 3.0, both of them are available via that PPA repository.

The problem is, if you now download mother-package-3.0.deb from the repository page and try to install it with gdebi, you'll (or gdebi) fail.

Because, checking the mother-package-3.0.deb file, gdebi knew that this mother-package needs child-package of version 3.0 or higher, but It only knows the location of version 2.0. It doesn't know where to fetch the version 3.0 of child-package from. This is expected because, You didn't tell the system where you get this latest mother-package. In other words, You didn't configured the repository list to include that PPA.

So, the Obvious answer is of this question is It depends. If the necessary dependencies can be found in already configured repositories, the installation will be successful. But if not, then it'll fail to install this highered versioned package. That's why you still need PPAs and that is the easiest way without manually doing all these.

The second part of the second question didn't make sense to me.

I had the same issue with few applications, with skype being one of them, these depend on external packages or library files that need to be installed manually.

To fix the issue i used :

sudo dpkg -i skype.deb

And then after being prompted for the external libraries like you have in your output, i typed in:

sudo apt-get install -f

This downloaded the required packages and installed skype all by itself.

In every .deb package there is a list of dependencies (with the compatible version number).

I'm not a Python reader but the source code seems to make a call to apt to get that list. It's obviously got to be recursively descended to find the dependencies of the dependencies but apt can obviously do that as well.

Once the dependencies are all worked out and placed in the correct order (some dependencies need to be installed before other dependencies can be installed), apt is simply asked to install the dependencies. Then the package which was given as an argument to Gdebi is installed.

The dependencies and the target package are installed in two operations for two reasons. First the format of an apt call to install a local .deb is different from an apt call to install dependencies from a repository. Second, separating the calls ensures the dependencies are all installed before the target package.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.