3

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
6

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.

1

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
0

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.

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.

  • 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 clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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