Re: aptitude problem WAS: Re: NMU and hijacking of gnome-apt
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)
Do you mean that I should put some examples after the first paragraph?
SEARCHING, LIMITING, AND EXPRESSIONS
Aptitude sports a fairly powerful system for searching for particular
packages and limiting the package display. Users familiar with mutt will pick
up quickly, as it was the inspiration for the expression syntax.
A search expression contains one or more "search terms" in a row. Each
search term specifies some condition which must be true: for example, the
section of the package, or the package's installed state. If this condition
is true, the search term is said to "match" the package.
A search term can consist simply of a series of characters; eg, "gnome".
In this case, it will match the name of the package.
For more complex searches, it can consist of a tilde (~) followed by a
single character describing the type of search term desired, and then possibly
a string to be matched.
There are two types of search terms: those which match against a string,
and those which do not. For those which do not, you simply write '~<type>'
and are done. For example, "~b" will match any broken package. If you are
using a search term which requires a string to be matched, you must write the
string immediately following the search type. For example,
~mDaniel Burrows
will match all packages which I maintain.
Whitespace is significant within search terms, even at the beginning and
end. In other words, "~mDaniel Burrows" and "~m Daniel Burrows" are
two different search terms, the second of which will not match anything
at all!
To require that a search term not be matched -- that is, to describe the
opposite of a search term -- type '!' in front of it. For example: !~v
will match any package which is not a pure virtual package.
Search terms can also be grouped together. To require every one of several
search terms to be matched (an "and" matching), write them one after another,
as so:
~b ~snet~nhttp
This will match any broken package in the section "net" whose name contains
"http". You can require that any one of several search terms be true by
placing "|" between them (an "or" matching):
~b|~v
will match any broken package or any pure virtual package. Finally, placing
parentheses around a group of terms will cause them to be grouped into a single
meta-term. This is useful for combining "and" and "or" in one expression.
For example:
~b(~mDaniel Burrows|~snet)
will match any broken package which I maintain or which is in the "net"
section.
.
.
.
-> Expressions are used to limit the display of packages
The second application is perhaps even more powerful than searching. An
expression can act as a filter for the display of packages: any packages which
match the expression are displayed, any which don't are not. The default is to
display all packages; you can type 'l' while running the program to change it,
or set the configuration option Aptitude::Pkg-Display-Limit.
A quick example: a limit of
!(~snon-free|~scontrib)
will hide all packages in non-free or contrib.
It then goes on to exhaustively list all possible search terms.
> - 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.
> - 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..
> > > 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.
> and what does [X] Allow packages to be reinstalled menu item mean? Is
> that the one you refer to?
That allows you to reinstall packages, exactly as with
"apt-get --reinstall". I'm not sure why the option is there; in the
past I may have found it useful to avoid accidentally reinstalling or
something.
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.
> > > 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")
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.
> > 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.
Daniel
--
/-------------------- Daniel Burrows <dburrows@debian.org> -------------------\
| If you wish to live wisely, |
| ignore sayings--including this one. |
\-Evil Overlord, Inc: planning your future today. http://www.eviloverlord.com-/
Reply to: