On Fri, Oct 27, 2006 at 08:02:24AM +0200, Frank Küster <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 26, 2006 at 11:33:07AM +0200, Frank Küster <[EMAIL PROTECTED]> > > was heard to say: > >> The simple practical solution to this particular problem will be to > >> remove preview-latex from the archive as soon as auctex has reached > >> testing. But I think something's seriously wrong with aptitude's > >> decisions: It should not ignore the Conflicts/Replaces/Provides just > >> because there's a newer version of preview-latex available. > > > > There may be ways of improving it, but I guess I'm missing the problem > > here -- it couldn't figure out how to upgrade auctex without breaking > > other software, so it held it back instead. > > preview-latex is now part of auctex. Technically, this is implemented > by using the documented triple incantation "Conflicts/Replaces/Provides: > preview-latex". > > What else should a package do to take over an existing one? Should the > fact that there is a newer version of preview-latex also available > (which could well be a not-yet-done security update or similar) really > have the consequence that nothing is done instead?
Yeah, I did eventually remember what C/R/P meant. The ideal way to handle it in the resolver would be to give a bonus to removing a package iff the removal was directly due to the C/R/P (or maybe not -- see below). Unfortunately, this has the drawback that it breaks an important property of solutions: right now, aptitude relies on the fact that the score of a solution is a pure function of the contents of the solution (not, eg, a function of how you got to the solution). Obviously, I didn't think about this case when designing the resolver. :-) I don't think I want to change that in general. One solution I see is to just add a bonus to removing any package that's the target of an active C/R/P. That might work, but it feels hacky and possibly error-prone (what if we need to keep the package, or cancel the upgrade of the C/R/P source for some other reason?) And the big problem is that this is independent of why the package is being considered for removal -- even if the replacing package isn't being considered for installation at all, aptitude will still tend to want to remove the replacee whenever it has the option. Even the idea of giving bonus points depending on how a solution was arrived at has some issues. I think I could probably implement this (IIRC, aptitude mostly uses the "solution content is identity" trick to exclude redundant paths, and I could instead only recalculate redundant paths if the new path has a better score -- as long as past moves don't affect the values of future moves, we should be ok). This leaves some questions open too, though -- e.g., what happens if several packages all completely replace the same package? Should aptitude try harder to replace that package or shouldn't we care? If removing a replaced package means that other packages get broken and have to be removed (can happen if, eg, the replacee has provides the replacer doesn't or if packages have versioned dependencies on the replacee), should we really plow ahead and do it? That's what will happen if the score for obeying C/R/P is too high. All in all, I think this can probably be solved, but it's not trivial and risks making the resolver take longer to produce worse results. The current results are IMO not a disaster (they require manual intervention but won't hose the system -- you'll just have to give aptitude a poke to try harder to upgrade some packages), so we may have to live with the current situation for etch. Daniel
signature.asc
Description: Digital signature
