On Wed, Mar 08, 2000 at 08:26:00AM -0500, Daniel Burrows was heard to say:
> > What gets me is that aptitude, apt-get, deselect, and gnome-apt all
> > seem to give slightly different info on which packages
> > are broken, will be deleted, or are on hold. Are the
> > dependancy rules interperted differently between these
> > programs?
> dselect probably uses a totally different algorithm from the others
> As for the apt-based programs: there are a number of
...argh..I need to get more sleep.
Anyway, if you're talking about what happens when you modify a package state,
there are a couple of variables that control what happens and a couple of
different notions of "broken". For example, you can test separately whether
a package is broken now or will be broken after all installs and so on are run.
After fiddling with the options a little, I decided to display packages as
'broken' in either case. Selecting packages can also just select that package
or select all its dependencies and remove conflicts. I don't remember what
gnome-apt or console-apt do in this regard; to turn this behavior on in aptitude
(which I don't like as it has hard-to-see side effects), set
Aptitude::Auto-Install to "true" in /etc/apt/apt.conf.
Also, aptitude tries by default to fix any broken packages, but doesn't use
one of the canned routines (I tried and they didn't work well for my
purposes..any suggestions on how to go back to them are accepted :) ) -- instead
it directly accesses the problem-resolution code. Unfortunately that was a
while ago and I don't remember precisely what the problem with pkgFixBroken
It is hard to think of anything less sentient than a pumpkin.
-- Terry Pratchett, _Witches Abroad_
- From: Kenneth Scharf <firstname.lastname@example.org>
- Re: aptitude
- From: Daniel Burrows <Daniel_Burrows@brown.edu>