On Tue, Dec 16, 2014 at 12:53:53PM +0100, Benjamin Drung wrote: > 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. This is because candidates aren't effected by dependencies, but by 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
Attachment:
signature.asc
Description: Digital signature