apt-get not properly resolving a dependency on a fixed version in a Debian/Ubuntu package

Question

I have a custom package foo with a dependency in the control file on a fixed version of another package bar:

Depends: bar (= 1.2.3)

Both the foo and the bar packages are published in my own repo. Furthermore I have multiple versions of bar in the repo, say, 1.2.3 as well as 2.1.0. Now, when trying to install foo on a new machine using

apt-get install foo

it fails with

The following packages have unmet dependencies:
 foo : Depends: bar (= 1.2.3) but 2.1.0 is to be installed

I.e. apt-get does not appear to correctly figure out the proper versions of packages to use.

I tried adding a conflicts:

Depends: bar (= 1.2.3)
Conflicts: bar (>> 1.2.3)

but that only resulted in the error changing to

The following packages have unmet dependencies:
 foo : Depends: bar (= 1.2.3) but it is not going to be installed

If I specify the version of bar while installing, that works:

apt-get install foo bar=1.2.3

But this is not feasible (the real case has multiple levels of dependencies and I really don't want to have to implement my own dependency resolver in order to find and specify everything manually on the command-line - might as well skip apt in that case).

So the question is, is there any way to get apt to behave properly and automatically install the correct versions of the dependencies (without having to explicitly specify those versions on the command line)? And I should add that I also really don't want to have to go the apt_preferences route with version pinning, as that requires managing versions in two separate places.

For completeness sake, here's the full output when turning on various apt debugging output:

apt-get -o Debug::pkgProblemResolver=1 -o Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgDepCache::Marker=1 install foo

Reading package lists... Done
Building dependency tree       
Reading state information... Done
  foo:amd64 Depends on bar [ amd64 ] < none -> 2.1.0 > ( universe/utils ) (= 1.2.3) can't be satisfied!
Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) foo [ amd64 ] < none -> 1.0.0 > ( misc )
Broken foo:amd64 Depends on bar [ amd64 ] < none -> 2.1.0 > ( universe/utils ) (= 1.2.3)
  Considering bar:amd64 0 as a solution to foo:amd64 9998
  Re-Instated bar:amd64
Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 foo : Depends: bar (= 1.2.3) but 2.1.0 is to be installed
E: Unable to correct problems, you have held broken packages.

Answer 1

The apt resolver does not consider the possibility that you might want to install something that is not the most recent available version of a package in a given target release; Debian just doesn't support installing anything but the most up to date version of a package for your system.

If you're using different repositories for each version of a (set of) package(s), then you can use pinning to prefer a given origin, or give them a different codename and use apt's -t option to select the target release. Otherwise it's just not possible.

Answer 2

I know it's a bit late to help OP, but I still find it difficult to Google solution to this problem that actually works. Where apt-get fails, aptitude resolver is able to come up with a successful solution with a little hint:

aptitude install -o "Aptitude::ProblemResolver::Hints::=reject foo :UNINST" foo

The above hint basically says the dependency resolver to reject all solutions that involve "not installing" the foo package and forces aptitude resolver to try harder than apt-get can.