Feedback

type to search

Welcome

Wiki pages

Top 5 groups

Top 5 users

Recent badges

Packaging: "Depends" on a specific package version problematic if a newer package exists?

Asked by , Edited by Fernando C. Estrada [ Admin ]

I package my own software as .debs so I can deploy it more easily. I’ve run across a problem regarding dependencies across package versions.

I’ve got two packages, call them foo and bar, both available in two versions, say 1.0 and 2.0. Package foo 1.0 depends on bar 1.0, so I’ve put something like this in the control file: Depends: bar (= 1.0).

However, installation now fails with a message similar to “foo: Depends: bar (= 1.0) but 2.0 is to be installed”

How do I do this?

NN comments
davehaste
-

I am also experiencing this problem. It seems like a massive shortcoming of an “advanced packaging tool” if it cannot be coerced into resolving this type of clearly-specified dependency automatically. I would be very interested in any potential (and automatable/scriptable) solutions to this.

or Cancel

3 answers

4

zack [ Admin ]

The problem lies in the ability to solve dependencies of the package manager you’re using.

According  to the error message, it looks like you’re using apt-get, which is well known to suffer for this kind of issue. In this specific case, aptitude will be able to work out the dependency problem and will propose you (interactively, if there are different choices) the obvious solution of keeping bar at version 1.0.

So, in short, if you use aptitude you won’t suffer from this specific issue.

Note however that you might stumble upon other dependency issues as no package manager is perfect (or, technically speaking, “complete”) in solving dependencies …. yet! :–)
NN comments
peter.sabaini
-

Thanks — right, this is with apt-get (and if possible I’d like to keep this scriptable, ie. non-interactive). Is there a (recommended) way to give additional hints to the package manager? Would ie. adding “Breaks:” or “Conflicts” help apt-get to choose the correct package?

Thanks again!

jordanm
-
.sabaini aptitude is not curses-interface only. It also works non-interactively like apt-get. IMO there are only some rare situations where you do not want to use it (such as resolving the depends of a .deb generated by mk-build-deps).

or Cancel
1

hadret [ Moderator ]

Well, default action for apt, aptitude and so, is to install the most recent version (except experimental). You can, for example, install this package manually if it necessary needs to be 1.0 and can’t be 2.0.
But better way is to actually allow package to install newer version, so in depends it would be like that: bar (>= 1.0).

NN comments
peter.sabaini
-

I agree in general the more recent the package, the better. In this specific case however, I need this exact version for reasons internal to that package. Remember, this is not about an official package but my own software. I just use the Debian packaging mechanisms for easy deployment.

And the documentation AFAICT says depending on a specific version should work (eg. here: http://www.debian.org/doc/debian-policy/ch-relationships.html ), so I’m not sure whats wrong here.

d.paleino
-
.sabaini Depending on a specific version is supported, but it obviously fails if you already have a different version installed. Is this your case? If yes, downgrading the package (see my reply) should work (but be careful! ;))

peter.sabaini
-
.paleino nope, neither version of neither package is installed at first.

or Cancel
0

d.paleino [ Editor ]

If foo can’t depend on bar (>= 1.0), you can force bar’s downgrade:


apt-get install bar=1.0

This way, you’ll force the installation of bar 1.0. When you’ll try to apt-get upgrade, bar will be kept at that version, unless you give “dist-upgrade” — in which case, foo would be removed.

You should be extra careful when downgrading a package -- it's not supported, so you'd need to downgrade also packages which depend on the newer version. This is not always possible though (say, missing older versions).
NN comments
peter.sabaini
-

That would of course work. Still, I’d like the dependency mechanism to take care of that. This would also work better with scripted installs etc. I wonder why the dependency mechanism doesn’t work as documented. Am I interpreting the documentation the wrong way?

d.paleino
-
.sabaini Yes. If you’re depending on “= 1.0”, and have already “> 1.0” installed, there’s not much our package managers can do. And you’re explicitely saying “I can only work with 1.0, no more, no less”. Also, we don’t support concurrent installation of multiple versions, unless the package name changed (see for example libraries changing package name when the SONAME changes). So you really need to pin your packages at the right version, downgrade the needed packages, or fix your local package to support “>= 1.0”.

peter.sabaini
-
.paleino As I stated before, at the beginning of this experiment, neither package is installed. The package manager need not downgrade an already-installed package, it just needs to install the correct, ie. older, version.

yuriy.gapon
-

Peter, have you found a solution for this problem? I see that it is one year old discussion..

We have exactly the same problem with debian dependencies, and we use it for exactly the same purpose – to package our own software for quick install.

Please let me know if you found a workaround for this one.

or Cancel

Your answer

Answer by email
You need to join Debian to complete this action, click here to do so.