On Tue, Mar 10, 2009 at 11:00:11AM -0400, C Sights <csig...@fastmail.fm> was
heard to say:
> Hi,
>
> > On Sat, Mar 07, 2009 at 10:46:56AM -0500, C Sights <csig...@fastmail.fm>
> > was
> heard to say:
> > > Aptitude is also ignoring the priority of the repositories:
> > > experimental=1 and unstable=500. This behavior is bug #473296 .
> >
> > That's actually just restating what I said above.
>
> Didn't mean to tweak you if I did. I was trying to help you merge
> bugs. (I
> don't know how to do that myself, and if I did I wouldn't trust my judgement
> enough to do it myself.)
No problem. I shouldn't have mentioned it.
> > Regardless, thanks
> > for the reminder: I'm working on the resolver right now and this is a
> > problem that can be neatly solved with the changes I'm in the process
> > of making...as soon as I can figure out how best to tweak them to
> > shoehorn apt preference information into the design. But all the
> > necessary machinery now exists, where it didn't when this bug was
> > filed; now it's just a matter of transmitting this requests to the
> > backend in a reasonably clean and configurable way. Hrm.
> >
> > (NB: this assumes that what you want is "always show solutions
> > containing a lower-preference package after all solutions that don't
> > contain lower-preference packages",
>
> I kind of understand what you are saying here, but it seems like an
> easier,
> more straight-forward way to _say_ it (at least) is "From all packages which
> satisfy a dependency, choose the highest priority package". A longer way to
> say it is "get all packages names which satisfy a dependency, then order them
> by priority (highest to lowest), then by version number (highest to lowest).
> Chose the first package in the sorted list."
That won't work: you need to handle things like situations where two
highest-priority packages from different dependencies can't be installed
together (because they conflict or have dependencies that conflict, for
instance). Dependency resolution is more complicated than just
traversing the dependency graph and making an optimal choice at each
step; otherwise, it would have been solved perfectly already. :-)
That aside (depth-first search can be tweaked to work with conflict
tracking etc), another problem is that your suggestion produces arguably
suboptimal results when a higher-priority package requires a
lower-priority one, because the locally optimal choice leads to a
globally worse result. Here's a simple example:
A has priority 500
B has priority 500
C has priority 400
D has priority 1
A depends on B | C
B depends on D
Should installing A pull in B (priority 500) and D (priority 1), or
should it pull in just C (priority 400)? Your rule would produce the
first result, but I think the second one is better.
> Maybe thinking in terms of entire solutions instead of individual
> packages
> makes more sense if you know the code. Or maybe I'm misunderstanding this
> bug (and it is not the same as bug #473296).
I stated things the way I did because it's a description of the
desired result rather than the details of how it's achieved, which means
we can discuss the important stuff without getting into stuff that's
only important inasmuch as the result has to be achievable. Here's an
example of what I meant: if you have two possible solutions to a
dependency problem, and one contains only packages of priority 500 or
greater, and another contains a package of priority 1, the priority-500
solution will be produced first. [0] Right now aptitude is not capable
of providing any "hard" guarantees about solution ordering, so even to
the extent that it does try to order solutions, that ordering could be
violated at any time.
The next release will be able to provide some hard guarantees under
technical conditions that I won't bore you with unless you're
interested. :-)
Daniel
[0] there are some other constraints on solution order that I want to
impose; this is probably the "last step" in the ordering, after
solutions are otherwise equal.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
