DEB: "Provides:" field ignored

Question

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?

EDIT:

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 <administration@tao.at>
Build-Depends: debhelper
Standards-Version: 3.8.0
Homepage: http://tao.at

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
Versions: 
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: 
  tao-firewall,tao-xen-utils-common
  tao-firewall,tao-xen-utils-common
Dependencies: 
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)) 
Provides: 
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:
  xen-utils-common
Suggested packages:
  xen-docs-4.0
The following packages will be REMOVED:
  tao-xen-utils-common
The following NEW packages will be installed:
  xen-utils-4.0 xen-utils-common

Edit:

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

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
One more thing: if you are using i686, is it possible that the package is being requested because it has a x64 version? (or vice-versa) — Mei, Feb 21 '12 at 15:53
Seems to me that no default install of Ubuntu will be x64 only; thus perhaps the installation is trying to get the i686 version and you're not "Providing" it. What if you create both a x64 version and an i686 version? You could use a metapackage if you wanted to (for the i686 version). — Mei, Feb 21 '12 at 16:09
Ahem. This is Debian, *not* Ubuntu. :) Also, it is already installed (as are other packages with architecture "all" and only having packages lying in the x64 folder of the repo). — Creshal, Feb 21 '12 at 16:13

score 7 · Accepted Answer · answered Sep 17 '12 at 20:46

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.

score 2 · Answer 2 · answered Aug 18 '17 at 14:36

The section of the Debian Policy Manual quoted in @cavedon's answer is still unchanged, but outdated. Since dpkg 1.17.11 setting a version on a provided package is possible. From the changelog:

Add versioned Provides support:

Add a new dpkg --assert-versioned-provides command.

Packages can provide a specific version, “virtual (= 1.0)” which will be honored, previously it would just be accepted when parsing.

Non-versioned virtual packages will not satisfy versioned dependencies.

Versioned virtual packages will satisfy non-versioned dependencies. Based on skeletal code by Ben Collins . Closes: #7330, #24934, #112131, #134582, #180316

So to solve the original example, in the control file you add a line

Version: *version*

(replacing *version* with the actual version) and replace the line

Provides: xen-utils-common

with

Provides: xen-utils-common (= ${binary:Version})

I hope it is ok to post an answer to such an old question, I just wanted to have this written down somewhere and editing @cavedon's answer didn't seem the right approach (the answer was right at the time and still remains potentially relevant on old systems). — imsodin, Aug 18 '17 at 14:39

score 0 · Answer 3 · answered Feb 22 '12 at 08:51

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.

score 0 · Answer 4 · answered Feb 22 '12 at 09:52

0

"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.

answered Feb 22 '12 at 09:52

raphink

11,337
6
36
47

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

DEB: "Provides:" field ignored

4 Answers4

Linked