Sometimes, there are several packages which offer more-or-less the same functionality. In this case, it's useful to define a virtual package whose name describes that common functionality. (The virtual packages only exist logically, not physically; that's why they are called virtual.) The packages with this particular function will then provide the virtual package. Thus, any other package requiring that function can simply depend on the virtual package without having to specify all possible packages individually.

All packages should use virtual package names where appropriate, and arrange to create new ones if necessary. They should not use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in the list of virtual package names. (See also Virtual packages - Provides, Section 7.5)

The latest version of the authoritative list of virtual package names can be found in the debian-policy package. It is also available from the Debian web mirrors at /doc/packaging-manuals/virtual-package-names-list.txt.

A virtual package is one which appears in the Provides control field of another package. The effect is as if the package(s) which provide a particular virtual package name had been listed by name everywhere the virtual package name appears. (See also Virtual packages, Section 3.6)

If there are both concrete and virtual packages of the same name, then the dependency may be satisfied (or the conflict caused) by either the concrete package with the name in question or any other concrete package which provides the virtual package with the name in question. This is so that, for example, supposing we have

Package: foo
Depends: bar
and someone else releases an enhanced version of the bar package they can say:

Package: bar-plus
Provides: bar
and the bar-plus package will now also satisfy the dependency for the foo package.

If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied (or the prohibition violated, for a conflict or breakage). In other words, if a version number is specified, this is a request to ignore all Provides for that package name and consider only real packages. The package manager will assume that a package providing that virtual package is not of the "right" version. A Provides field may not contain version numbers, and the version number of the concrete package which provides a particular virtual package will not be considered when considering a dependency on or conflict with the virtual package name.[52]

To specify which of a set of real packages should be the default to satisfy a particular dependency on a virtual package, list the real package as an alternative before the virtual one.

If the virtual package represents a facility that can only be provided by one real package at a time, such as the mail-transport-agent virtual package that requires installation of a binary that would conflict with all other providers of that virtual package (see Mail transport, delivery and user agents, Section 11.6), all packages providing that virtual package should also declare a conflict with it using Conflicts. This will ensure that at most one provider of that virtual package is unpacked or installed at a time.
http://www.debian.org/doc/debian-policy ... ships.html

But still i dont understand what is going on here....

DonKult

Post subject: RE: Virtual packages like Posted: 17.02.2012, 17:45

Team Member

Joined: 2010-09-02
Posts: 485

Status: Offline

Virtual in this context is 'even more' virtual than in what you found in the policy.

Virtual here means that some package refers this package in one of it's dependencies (e.g. 'Conflicts: opera') but a package 'opera' doesn't exist (for APT as it is neither installed nor available in a repo). Further more, no package declares that it 'Provides: opera' (which is what the policy refers, too) - if a package would do APT would have printed: 'Choosing foo instead of bla' (or something similar, to lazy to check the source now).

Are you sure that you mean opera? Maybe you have opera-next installed instead. The clever opera maintainers could have said 'Provides: opera', but heh, since then are non-free maintainers clever… (they properly just said: 'Conflicts: opera' in opera-next creating the 'virtual' opera package)

Otherwise lets see what
dpkg -l '*opera*'
gives us.

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor

Probably, that virtual thing had made opera very slow and that was the reason to purge it.

It was opera... (I think ), installed from the official opera repo. Any way, no more packages anymore outside official debian and aptosid repos.
The post is only for educational purposes.
Regards
snvv

DeepDayze

Post subject:Posted: 18.02.2012, 15:38

Joined: 2010-09-11
Posts: 616
Location: USA
Status: Offline

Opera is not available in debian, so maybe you might need to get the assistance of opera community to resolve that issue with the virtual package

what about doing as root:

Code:

dpkg -P opera

does that fix it?

snvv

Post subject:Posted: 18.02.2012, 15:51

Joined: 2010-09-13
Posts: 331

Status: Offline

Thank you, butOpera does not seem to be in my system anymore, and I am not going to install it again.
The error message probably was a cosmetic one. I do not know.
Regards
snvv

DonKult

Post subject:Posted: 18.02.2012, 16:29

Team Member

Joined: 2010-09-02
Posts: 485

Status: Offline

Just checked: Everyone can reproduce it, it's the mozplugger package mentioning opera in it's depends line (as one of many alternatives).

But as said, that's not a bug, not a problem nor does it cause anything. Beside that APTs 'error' message would have been a different one ("Unable to locate package opera"). opera is not installed either way.

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor