Re: aptitude problem WAS: Re: NMU and hijacking of gnome-apt
Daniel Burrows wrote:
>
> On Tue, Nov 27, 2001 at 06:20:56AM -0800, Erik Steffl <steffl@bigfoot.com> was heard to say:
> > > 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
>
> "limit" is definitely a correct word, and other programs use it (eg,
> mutt)
>
> If people find it confusing I could change it to "filter"; however,
> the keybinding to change the current limit is "l". Changing this would
> likely confuse current users; changing the name and not the keybinding
> would confuse future users, and changing the keybinding to something
> obvious is hard, because "f" is already taken.
>
> I should add that you're the only person I've ever heard of who has
> had this confusion.
>
> > - include example/explanation right where the desription of this is in
> > README
>
> There is an explanation (in the README), and it even has examples.
> (erg, that verb "sports" is kind of silly. I must have been feeling
> particularly British)
I was talking about this section:
Aptitude::Pkg-Display-Limit
The limit applied to packages being inserted
into the
display (empty for no limit)
default: ""
which is the explanation of the particular option, the first thing
I've found. Of course, have I read the whole document I would find the
section on searching, limiting and expression...
> Do you mean that I should put some examples after the first paragraph?
...paragraph snipped...
not really, the problem is that I didn't even find paragraph (it's my
fault, but I want software to make up for my faults whenever possible).
That's where identical naming would help (same string used in config
dialog, config file and help file)
> > - make it apply right away or warn that it will not apply until
> > aptitude is restarted
>
> The problem here is "how should it apply?" Remember that it's only
> a default -- you can change the limit of an individual display as well
> (and I often do)
>
> I suppose I could change the limit in any display whose limit matches
> the old default exactly or something.
each view could remember whether the limit (and other options) was
changed, if yes, new defaults would be ignored, if not then new default
would be applied. you can achieve the (almost) the same functionality by
comparing values but IMO it's a lot cleaner and easir to maintain when
you use the status of the view to keep the info.
the lazy way to 'fix' it would be to add a message saying that changed
options are only applied to new views (not a separate message box, just
one line in the options dialog).
> > - use the same name in dialog and README (and config file) [this one's
> > kinda nitpicking, the names are almost the same]
>
> One place says "the limiting expression for the display"; the other
> says "the display-limit". The main reason for the second one is
> probably that I only have a limited amount of screen space on a standard
> terminal..
well, display-limit is the one used in dialog so I used that one to
search docs, I found what looked like THE explanation of this option...
IMO the heading for the section on searching should (be)|(include) the
exact phraze from dialog. Of course, even better option is to have
context sensitive help.
> > > > 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?
>
> I was a little loose in my language above. (this is a side effect of
> the fact that the two operations are identical internally)
>
> Upgradable packages (packages which are installed, but for which a
> newer version is available; also those shown as "upgradable packages") are
> marked to be upgraded. All of their dependencies are marked to be installed
> if they are not installed, or upgraded if they are upgradable and are not
> held.
>
> Packages to be installed are packages which are not yet installed.
> Packages to be upgraded are packages which are installed and will be
> upgraded.
> Um. Pacakges being downgraded might be listed strangely there, need
> to add that to the list of things-to-do.
I am more and more confused. the problem was that I didn't ask for any
new packages to be instlled and yet there was list of more than 20
packages to be installed. (apt-get didn't want to install any new
packages)
> I was referring to "automatically upgrade installed packages".
> The only clearer phrasing I can think of is
> "automatically upgrade upgradable packages", and that looks strange.
ok, it's clear, I just wasn't sure what you mean in relation to my
question about why there are so many new packages to be installed. Now I
see that's different problem, see below.
> > > > 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).
>
> I looked at the list of packages declaring dependency relationships on
> cupsys (press Enter on it and scroll down, or press "r")
I used apt-cache show lpr-ppd (it show that it conflicts with cupsys)
but apt-cache show cupsys doesn't say it conflicts with lpr-ppd... not
sure if it's bug or feature... (looks like a bug but there might be some
reason to do it this way).
> Better reporting of broken dependencies is an old wishlist -- but I
> don't really like the way dselect does it, and I haven't had the time
> to come up with a better option, or code it.
> I've gotten a number of complaints about this lately, so I might
> take a harder look at it. Something dselect-like might be a good first
> step, since it's a known target.
>
> > 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?
>
> Possibly the conflict is only in a new version of lpr-ppd.
>
> > > > 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).
>
> IMO, this information is not low level.
well, maybe the low-level is not the best expression, what I mean is
that no matter which front-end I use I expect the status of the packages
to be reported in exact same way - I expect all of the front end tool to
tell me which packages are installed, which are held etc... front ends
can provide different functionality in addition to this basic
functionality but all of the front ends should be easily replacable and
all changes should be reflected in all of them.
perhaps I want too much but when I put the package on hold I want it
to be on hold. debian spoiled me a lot:-)
> > > 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...
>
> Well, define "screwed up info", and that would be a start.
well, before I removed the pkgstates it showed fairly bogus info (it
wanted to install huge number of packages, it showed seemingly random
packages to be on hold etc.). When I removed the file and started
aptitude it shows the same info as apt-get (which seems ok).
therefore I consider info it had before screwed-up, but I cannot
specify how exactly. Basically, the info that aptitude uses should be
kept in synch with info that aptitude used to recreate removed file, or
something like that. With this I come back to the wishlist bug (not
filed, so far I only suggested it on mailing list) against debian
packaging system - all front-ends should work with the same basic info
about packages, where basic means all the info about packages - which
are to be installed, which are held, which packages are available etc.
why would apt-get show different packages then dpkg -l? why would
aptitude hold different packages than apt-get? etc. (data are kept by
what I called low-level system, front-ends provide view on the data and
perform operations on data - generally data structure changes a lot less
often then functionality of programs operating on the data so it makes
sense).
erik
Reply to: