Re: aptitude problem WAS: Re: NMU and hijacking of gnome-apt
On Tue, Nov 27, 2001 at 01:28:55AM -0800, Erik Steffl <steffl@bigfoot.com> was heard to say:
> > I certainly wouldn't release a version that was this broken [1], so if
> > you see something like this you should assume that either (a) you're
> > doing something wacky, or (b) I don't know about it! (or (c) it's in
> > the BTS already, but this isn't)
> >
> > You wouldn't happen to have set a limit on your display and then
> > forgotten it, would you?
>
> no, but it was set to 10. not sure to what it applies. I changed it
> to empty string (that's what README says means unlimited)
That will cause all packages whose package name does not contain 10
to be hidden.
How did you set and unset it?
If you set it in a configuration file you'll have to change it there
(pressing "l" just changes the limit for the displayed view)
Changing the default limit doesn't alter the limit of active views
(this is deliberate, as you may have changed the limit of a view to
something other than the default)
> it lists a lot (20+) of packages to be installed (status is pi), I did
> not ask to install anything. It lists packages to upgrade but those are
> not the same as the one apt-get lists. etc..
It automatically marks all upgradable packages and their dependencies
for installation. You can disable this in the "miscellaneous" options
menu.
> package cupsys is listed in section [+] Packages to be removed, when I
> hit enter I see the info about package with no broken dependencies, only
> two packages in Suggests section are red and say (UNSATISFIED). why does
> it wnat to remove this package?
Two possibilities:
(a) cupsys is conflicted upon by something else. (doubtful)
The only such package I see is lpr-ppd.
(b) it's showing information about the wrong version of cupsys.
This will be fixed when I release another version (it's fixed in
CVS) -- basically, the way that aptitude chooses which version to
display is nonintuitive.
You can explicitly find and select the broken version by pressing "v".
The best way to find out what's wrong might be to override its decision,
then see what breaks.
There's one other bug that might cause this, but I don't know whether
it even exists any more.
> the list of packages listed as being held is different in apt-get and
> aptitude.
This is because aptitude uses its own list of held packages. (yes,
I've never gotten around to merging it into the dpkg list)
> is this material for bug report? what information do you need from me
> to get some idea what's going on?
A copy of /etc/apt/apt.conf and ~/.aptitude/config would be a good
start.
More delving into why various packages are being selected for removal
would be helpful.
> > This indicates that some packages which you have forced to be held
> > would be broken by the install, no matter what it does. I think that's
> > an error message from libapt, so I can't do much about the wording.
>
> yes, I did. however apt-get simply lists them as being held back and
> works with the rest of packages, aptitude doesn't even list the same
> packages.
I suspect that you have packages on hold in aptitude.
You could try removing /var/state/aptitude/pkgstates (and
~/.aptitude/config?), and see if that helps get things back to a sane
state.
Daniel
--
/-------------------- Daniel Burrows <dburrows@debian.org> -------------------\
| Genius may have its limitations, |
| but stupidity is not thus handicapped. |
\------- Listener-supported public radio -- NPR -- http://www.npr.org --------/
Reply to: