[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: aptitude removals (was Re: APT 0.7 for sid)



On Sun, Jun 10, 2007 at 08:13:18PM -0400, Felipe Sateler <fsateler@gmail.com> was heard to say:
> Daniel Burrows wrote:
> 
> >   Bug #299009 is AFAIK about the fact that aptitude produces different
> > dependency resolutions from the visual UI versus the command-line.  This
> > is because the command-line has more context about what the user is
> > doing and tweaks the resolver accordingly. 
> 
> Would you elaborate on that, please? I don't get why the command line has
> more context. In your response to that bug report you said: 

  That's a good question, and I've thought about it from time to time.
Probably when I take a crack at this bug again, I'll at least take a shot
at unifying the approach taken in the two frontends.

  TBH, what I wrote above was just paraphrasing (parroting) my comment in
the bug report.

> I fail to see the difference between "aptitude install X Y Z" and going into
> the visual mode and then marking X Y Z for installation. Where is the extra
> information?

  I think what I meant was that out of the whole world of packages in
the cache, you mainly care about X, Y, and Z.  You don't care (much)
about packages that get dragged in by them, or about packages that are
being kept at their current version but that you didn't mention.

  However, I think that a similar effect can probably be achieved in
visual mode by adding a massive bonus to the current version of all
packages being manually installed, removed, or upgraded, along with
all held packages.

  I may also have been worried about the possibility that the resolver
would get stuck on trying to avoid changing your selections, even if
it turned out to be necessary to do so.  But experience has shown that
the opposite is the case: giving strong hints to keep user selections
produces better results than otherwise (hence aptitude sets
request-strictness to 10000, which pretty much guarantees that you
don't see solutions that change your selections unless there's
no alternative).

  And on the third hand, it's entirely possible that I didn't have a clue
what I was talking about in 2005.  Also, the resolver was new back then
and I didn't have as good a feeling as I do now for how it behaves, so
I was being pretty cautious about tweaking its weights.


  Anyway, this is getting offtopic -- maybe we could take it to private
mail if you want to talk more about dependency resolution.

  Daniel


-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: