Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need to replace a package with a custom one, which gets its own name (foo-origpackage). To allow it to be used as drop-in replacement, I added the Provides: origpackage line to the control file. apt-cache show foo-origpackage lists the "Provides" entry just fine. However, when I want to install a file depending on origpackage, it fails ("Package origpackage not installed").

Is there some distinction between "real" and virtual packages I'm missing?


To be precise, what I want to replace is xen-utils-common for Squeeze. My tao-xen-utils-common has the following control file:

Source: tao-xen-utils-common
Section: kernel
Priority: optional
Maintainer: Creshal <>
Build-Depends: debhelper
Standards-Version: 3.8.0

Package: tao-xen-utils-common
Architecture: all
Depends: gawk, lsb-base, udev, xenstore-utils, tao-firewall
Provides: xen-utils-common
Conflicts: xen-utils-common
Replaces: xen-utils-common
Description: Xen administrative tools - common files (modified)
 The userspace tools to manage a system virtualized through the Xen virtual
 machine monitor.
 Modified for use with TAO Firewall.

Installing xen-utils-4.0 fails, however:

foo@bar# apt-cache showpkg tao-xen-utils-common
Package: tao-xen-utils-common
4.0.0-1tao1 (/var/lib/apt/lists/repo.tao.at_dists_stable_main_binary-amd64_Packages) (/var/lib/dpkg/status)
 Description Language: 
                 File: /var/lib/apt/lists/repo.tao.at_dists_stable_main_binary-amd64_Packages
                  MD5: 7c2503f563fca13b33b4eb3cbcb3c129

Reverse Depends: 
4.0.0-1tao1 - gawk (0 (null)) lsb-base (0 (null)) udev (0 (null)) xenstore-utils (0 (null)) tao-firewall (0 (null)) xen-utils-common (0 (null)) xen-utils-common (0 (null)) 
4.0.0-1tao1 - xen-utils-common 
Reverse Provides: 

foo@bar# apt-get install xen-utils-4.0
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
Suggested packages:
The following packages will be REMOVED:
The following NEW packages will be installed:
  xen-utils-4.0 xen-utils-common


foo@bar# apt-cache policy xen-utils-4.0
  Installed: (none)
  Candidate: 4.0.1-4
  Version table:
     4.0.1-4 0
        500 stable/main amd64 Packages
     4.0.1-4 0
        500 stable/updates/main amd64 Packages

share|improve this question
Asking the obvious: when it says Package origpackage not installed, is it true that foo-origpackage is actually installed on the system? – Mei Feb 21 '12 at 15:01
Yes, it's installed. If I add "Conflicts: origpackage", it also prompts to remove it. – Creshal Feb 21 '12 at 15:16
Is it possible that "origpackage" is not enough? That is, perhaps it wants a specific version - or the package system is requesting something else? I think I'd take a look at the original package, and see what it has for Provides: - perhaps the "request" is for something else in the Provides: list... – Mei Feb 21 '12 at 15:29
The original package doesn't provide anything. – Updating original post with more information. :) – Creshal Feb 21 '12 at 15:33
How about output (when your package is installed) from apt-cache policy xen-utils-4.0? – Mei Feb 21 '12 at 15:52
up vote 4 down vote accepted

I spent quite some time investigating this same issue and I reached the conclusion that the the "Provides" is ignored because xen-utils-4.0 has a versioned "Depends" on xen-utils-common.

Quoting the Debian Policy Manual:

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.

If the Depends were unversioned, the provides would have been satisfied, however a Provides, which is always unversioned, can never satisfy a versioned Depends.

Unfortunately, I do not have a solution apart from what you have already proposed: keeping the same package name and having a higher version number.

share|improve this answer

Eventually mitigated the problem by renaming it back to xen-utils-common with a custom version, and making the package requiring the customization conflict higher versions. Thus, updates of xen-utils-common are blocked until I updated both packages.

Kinda works, but I'm open for better solutions.

share|improve this answer

"Provides" is only for virtual packages. If you want to replace a real package, you need to use "Replaces" and probably also "Conflicts" if the package provides the same files.

See Debian Policy, chapter 7.

share|improve this answer
As you can see in the listings, the package does have a "Replaces:" as well. – Creshal Feb 22 '12 at 13:59

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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