Re: aptitude problem WAS: Re: NMU and hijacking of gnome-apt
Daniel Burrows wrote:
>
> 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)
this is hellishly confusing, I though the limit is some number, the
description doesn't say anything and since I saw 10, I thought it should
be a number (I was tempted to put 0 there, or some large number, but
then I checked aptitude's README and saw that "" is no limit) - the
README doesn't say anything about the values (in description of display
limit, there is an example elsewhere in the file).
I have no idea how the '10' got in there, I don't remember putting it
there but I might have...
the other confusing thing is that it does not apply right away, as is
IMO reasonable to expect.
now I restarted aptitude and I see lot of packages. thank you, but it
would be even bigger thank you if you would make it less confusing:
- display limit: by using something that would suggest that it's sort
of filter, or pattern, AFAIK limit means more like border of an interval
(then again I am not a native speaker), e.g. display filter, display
pattern or something like that
- include example/explanation right where the desription of this is in
README
- make it apply right away or warn that it will not apply until
aptitude is restarted
- use the same name in dialog and README (and config file) [this one's
kinda nitpicking, the names are almost the same]
not that I'm telling you what to do, it's just that IMO any of the
above would help me and probably other users to understand what aptitude
does...
> > 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.
some of the packages are marked as packages to be installed and some
of them are marked as packages to be upgraded. what's the difference?
and what does [X] Allow packages to be reinstalled menu item mean? Is
that the one you refer to?
> > 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.
actually, that's the case. why doesn't aptitude say so? and how do you
know that it conflicts with cupsys? I mean the cupsys doesn't say so,
only lpr-ppd does (both in apt-cache and aptitude).
then the mystery is how come I have lpr-ppd installed on my system but
cupsys is on my system too? Could that be a bug of apt-get?
<irrelevant>
I also have no idea how come it was installed, nobody seems to depend
on it (nobody installed on the same day) and I didn't install it
explicitly (it was installed nov 19 so I guess I would remember that).
it was installed on the same day with apache-ssl,
cupsys-driver-gimpprint and printtool (apparently lpr-ppd and printool
were instelled togethher but why? anyway, that's another discussion)
</irrelevant>
> (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.
indeed, cupsys is marked i and lpr-ppd is marked B (and colored red)
> 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)
hope the low level package info will be merged and maintained by one
application only sooner or later (rather sooner than later).
> > 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.
I removed pkgstates, now it looks as it would do same thing apt-get
do, also the list of held packages is the same as the one from apt-get
(I didn't check each package but it looks roughtly ok).
isn't it possible for aptitude to figure out somehow that it has
screwed up info? when I deleted it and restarted aptitude it didn't take
longer than usual startup time to rebuild that info so I guess it
wouldn't hurt for aptitude to check the info...
sorry for all the (constructive) criticism but imo package
manipulation programs are the heart of debian (or at least one of the
hearts:-) so IMO they should be really good. I appreciate your help as
well as your work on aptitude.
erik
Reply to: