#773281 apt does not resolve equal (=) dependencies correctly

Package:
apt
Source:
apt
Description:
commandline package manager
Submitter:
Benjamin Drung
Date:
2015-08-14 07:45:03 UTC
Severity:
wishlist
#773281#5
Date:
2014-12-16 11:53:53 UTC
From:
To:
Hi,

the following bug is a major burden when working with Debian repositories that
contain multiple versions of one package. Image following example:

You have two packages named A and B. A in version 1 depends on B in version 1.
Apt will automatically install B=1 when you install A=1.

Now assume you have A available in version 1 and 2 and B in version 1 and 2. If
A and B are currently not installed, apt will try to install B=2 when you want
to install A=1. This fails of cause because of the package dependencies. This is
probably a bug in apt as it sees version 2 for B as the best install candidate
even if the dependency says different.

Steps to reproduce:
===============================================================================
#!/bin/sh
set -e

mkdir /tmp/alpha-1.0 && cd /tmp/alpha-1.0
dh_make -c mit -s -n -p alpha_1.0 -y
sed -i 's/^Depends: /Depends: beta (= ${binary:Version})/' debian/control
debuild -b
dch -v 2.0 'Bump version'
cd ../alpha-2.0
debuild -b

mkdir /tmp/beta-1.0 && cd /tmp/beta-1.0
dh_make -c mit -s -n -p beta_1.0 -y
debuild -b
dch -v 2.0 'Bump version'
cd ../beta-2.0
debuild -b

cd /tmp
apt-ftparchive packages . | gzip > Packages.gz
echo "deb file:///tmp/ ./" >> /etc/apt/sources.list
apt-get update
apt-get install alpha=1.0
===============================================================================

Apt throws following error message instead of installing alpha=1.0 and beta=1.0:

Reading package lists... Done
Building dependency tree
Reading state information... 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:
 alpha : Depends: beta (= 1.0) but 2.0 is to be installed
E: Unable to correct problems, you have held broken packages.

#773281#10
Date:
2015-01-05 10:57:05 UTC
From:
To:
pin-value and version number alone, which is a fundamental design
decision to limit the solver to explore a limited amount of solutions
instead of exploring waste amounts of them like e.g. aptitude does.

There is an exception for "A/release", which does some very basic
candidate flipping if it deems needed beside only A – usecase here is
experimental/backports were the higher versions are all not the
candidate. I guess you want the same for A=version, which could be more
or less easily implemented¹.  There are countless on and off-bug
references to this already, so I "fear" you want something more by
tagging it important…

So lets see why we haven't "more" so far:
For example, you absolutely don't want to flip the candidate based on
dependencies in (dist-)upgrade scenarios as this would potentially lead
to one obsolete package holding back everyone else. We do an automatic
hold on "Multi-Arch: same" desyncs, which is already borderline; doing
it on arbitrary dependencies and we would miss the line by a mile.

What I want to explore for stretch is if we can do syncs on source
packages, so that A:any and A-common:all are kept in check, but
I envision renames and split-ups/downs will complicate that dearly
(beside that we first need a good way to find source package info).


So if this is really just a A=version feature wish, please tag it
accordingly and ((semi-)optionally) find all the duplicates we already
have about it for merging (It would help tremendously).
If you want something more, you will have to provide some more details
on what that is exactly and why it isn't a problem to do it.


¹ extending pkgDepCache::SetCandidateRelease to consider switching to
the 'named' version in the dependency instead of flipping the version to
a named release is probably more than half of the task already. You
would have to consider some additional things though (pin and such), so
I wouldn't consider it 'newcomer', more a 'return-for-another-fix'.


Best regards

David Kalnischkies

#773281#15
Date:
2015-01-15 19:21:34 UTC
From:
To:
Am Montag, den 05.01.2015, 11:57 +0100 schrieb David Kalnischkies:

I can't remember any appearance of this bug where I didn't specified a
version. So, fixing the A=version usecase will solve the bug for me.

I haven't seen a similar bug report, yet.

Yes, I want just a A=version solution. With what should i tag this bug?
I haven't found any duplicates. I probably searched for the wrong words.