As taken from this link: https://www.debian.org/doc/debian-policy/#document-ch-relationships

There are 5 types of dependencies:

The meaning of the five dependency fields is as follows:

Depends

• This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured. The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. The Depends field should also be used if the postinst or prerm scripts require the depended-on package to be unpacked or configured in order to run. In the case of postinst configure, the depended-on packages will be unpacked and configured first.

• In the case of prerm or other postinst actions, the package dependencies will normally be at least unpacked, but they may be only "Half-Installed" if a previous upgrade of the dependency failed. Finally, the Depends field should be used if the depended-on package is needed by the postrm script to fully clean up after the package removal. There is no guarantee that package dependencies will be available when postrm is run, but the depended-on package is more likely to be available if the package declares a dependency (particularly in the case of postrm remove). The postrm script must gracefully skip actions that require a dependency if that dependency isn't available.

Recommends

• This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations.

Suggests

• This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable.

Enhances

• This field is similar to Suggests but works in the opposite direction. It is used to declare that a package can enhance the functionality of another package.

Pre-Depends

• This field is like Depends, except that it also forces dpkg to complete installation of the packages named before even starting the installation of the package which declares the pre-dependency, It works like this, when a package declaring a pre-dependency is about to be unpacked the pre-dependency can be satisfied if the depended-on package is either fully configured, or even if the depended-on package(s) are only unpacked or in the "Half-Configured" state, provided that they have been configured correctly at some point in the past (and not removed or partially removed since).

• In this case, both the previously-configured and currently unpacked or "Half-Configured" versions must satisfy any version clause in the Pre-Depends field. When the package declaring a pre-dependency is about to be configured, the pre-dependency will be treated as a normal Depends. It will be considered satisfied only if the depended-on package has been correctly configured. However, unlike with Depends, Pre-Depends does not permit circular dependencies to be broken. If a circular dependency is encountered while attempting to honor Pre-Depends, the installation will be aborted.

• Pre-Depends are also required if the preinst script depends on the named package. It is best to avoid this situation if possible. Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress.

Smaller Version:

• Both depends and pre-depends mention the dependencies a package needs before installing but pre-depends forces the installation and configuration of the dependency packages before even starting with the package that needs the dependencies. dpkg will not even unpack the main package until all pre-depend packages have been dealt with. With depends, the order of the dependency packages and the main one is not important. With pre-depends it takes into consideration this and also the verification if the pre-depends packages are configures and installed or not. Without this, the main package will not even be unpacked, configured or installed. You must either have the dependencies installed before starting the process of working with the main package. If not, they have to be downloaded/configured/installed first before proceeding. pre-depends are normally used in cases where the stability of the package is important and would not affect the system or program in a very bad way but this cases are avoided with several norms also mentioned in the link above.

The term "dependency" can be used broadly to encompass "Depends" and "Pre-Depends" relationships (and sometimes even other, weaker relationships), or it can be used narrowly as a synonym of "Depends."

The difference between "Depends" and "Pre-Depends" package relationships is that if X depends on Y, then Y must be fully configured before X gets configured. (Configuration is the installation step where a package, once its files are unpacked to the proper locations--i.e., once "installed"--has whatever other necessary changes made so that it is possible to actually use the software it provides. For example, configuration of an HTTP server might involve making sure there is a www user with proper abilities and a /var/www directory with proper permissions.) In contrast, if X pre-depends on Y then Y must be installed and (usually) fully configured before X is even installed.

See Section 7.2 of the Debian Policy Manual for more details. I quote the two most relevant sections here, but there is other information in that section (and in chapter 7 more generally) that helps to illuminate how dependencies work.

Depends

This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured (unless there is a circular dependency as described above).

The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality.

The Depends field should also be used if the postinst or prerm scripts require the depended-on package to be unpacked or configured in order to run. In the case of postinst configure, the depended-on packages will be unpacked and configured first. (If both packages are involved in a dependency loop, this might not work as expected; see the explanation a few paragraphs back.) In the case of prerm or other postinst actions, the package dependencies will normally be at least unpacked, but they may be only "Half-Installed" if a previous upgrade of the dependency failed.

Finally, the Depends field should be used if the depended-on package is needed by the postrm script to fully clean up after the package removal. There is no guarantee that package dependencies will be available when postrm is run, but the depended-on package is more likely to be available if the package declares a dependency (particularly in the case of postrm remove). The postrm script must gracefully skip actions that require a dependency if that dependency isn't available.

Pre-Depends

This field is like Depends, except that it also forces dpkg to complete installation of the packages named before even starting the installation of the package which declares the pre-dependency, as follows:

When a package declaring a pre-dependency is about to be unpacked the pre-dependency can be satisfied if the depended-on package is either fully configured, or even if the depended-on package(s) are only unpacked or in the "Half-Configured" state, provided that they have been configured correctly at some point in the past (and not removed or partially removed since). In this case, both the previously-configured and currently unpacked or "Half-Configured" versions must satisfy any version clause in the Pre-Depends field.

When the package declaring a pre-dependency is about to be configured, the pre-dependency will be treated as a normal Depends. It will be considered satisfied only if the depended-on package has been correctly configured. However, unlike with Depends, Pre-Depends does not permit circular dependencies to be broken. If a circular dependency is encountered while attempting to honor Pre-Depends, the installation will be aborted.

Pre-Depends are also required if the preinst script depends on the named package. It is best to avoid this situation if possible.

Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress.

You should not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached. See Dependencies, Section 3.5.