$ aptitude show ttf-unifont
Package: ttf-unifont
State: not a real package
$ apt show ttf-unifont
Package: ttf-unifont
State: not a real package (virtual)

That's a little better.

Hi Jidanni,

積丹尼 Dan Jacobson wrote:

I doubt that. To my knowledge "virtual" and "not a real package" are
equivalent. Adding that would only make sense if there are other types
of non-real packages. Otherwise it'd just be redundant and hence bloat.

Do you know of any other non-real package type than "virtual"?

		Regards, Axel

In this particular case, all I found was this package was mentioned in
other installed packages' headers.

I don't know if that makes it a virtual package or not.

Hi Jidanni,

積丹尼 Dan Jacobson wrote:

Thanks for this detail! And indeed, there are two types of packages
which can be seen as virtual or non-real package and it could help to
make a difference:

* Those provided by a package (can be installed, etc.) — those are
  officially called "virtual" in the Debian Policy.

* Those mentioned in package relations by other packages, but not
  (or no more) existing. Those exist in the dependency tree, but are
  not installable. I've seen those being called "virtual" as well, but
  I think that was never an official term for them. might have been a
  technical thing somewhere.

Both these types were also called "virtual" and I'm not sure which
terms should be used to distinguish between them. Aptitude calls the
latter usually "UNAVAILABLE" in the context of dependencies, but
something like "mentioned" or "referred to" seems more precise.

		Regards, Axel

(Challenge accepted!)

The message from apt is hardcoded, so same for all virtuals, but from
a theory point of view apt "knows" about four different types:
- pure virtual (= multiple providers)
- single virtual (= only one provider)
- mixed virtual (= a real package with that name also exists)
- missing (= the name only appears in dependencies)
(and of course the "normal" only-real packages)

You can see that being used in 'apt-cache stats' output.

The practical difference is mostly marginal and not really something we
concern users with all too much. Error messages are e.g. different if
the unsatisfiable dependency is a "missing" package.
Trying to install a mixed package will install the real package. While
a pure virtual will display an error listing the available options.
A single virtual package on the other hand will be automatically picked
with a notice and installed.
I haven't checked, but I presume aptitude behaves similar as that is
more or less a direct consequence of how libapt itself works or
something people actively complain about if it isn't working that way.


APTs source code has a FIXME in that place reminding us that we should
display here the possible providers (like we do for install as
mentioned). It isn't implemented yet through. On the other hand I highly
doubt we will expose the type of virtual in any real capacity to the
user. I would imagine 'missing' would just say that there is no
provider, while pure & single would display a list – mixed already shows
the info of the real package.


I presume the grant idea behind mentioning "virtual" here in apt is that
the user has another term available which might be easier to look up as
not everyone will know what a "not real" package even is – they all do
not exist in the physical space and are hence by definition all not
real/virtual?! If that is true or not is anyone's guess. I do not
consider it bloat on the apt side, but I also can't really consider it
missing for aptitude… we might agree on the fact that the list of
providers is missing here through. ☺


Best regards

David Kalnischkies

Also the user is curious where these determinations are drawn from.
It would be nice if aptitude said "Based on /var/lib/dpkg/status, this
package is a ephemeral / virtual / refereed etc. package."

Also some of them will show up as
v ...
in aptitude search
But some won't show up at all.
Confusing.