Am Montag, den 05.01.2015, 11:57 +0100 schrieb David Kalnischkies: > 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¹.
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. > There are countless on and off-bug > references to this already, so I "fear" you want something more by > tagging it important… I haven't seen a similar bug report, yet. > 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. 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. -- Benjamin Drung System Developer ProfitBricks GmbH - The IaaS-Company Greifswalder Str. 207 D - 10405 Berlin Mail: benjamin.dr...@profitbricks.com Fax: +49 30 577 008 598 URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506 B. Geschäftsführer: Andreas Gauger, Achim Weiss.
signature.asc
Description: This is a digitally signed message part
