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