[Aptitude-devel] Bug#656944: search shows wrong version

[Daniel Hartwig]

Control: clone -1 -2
Control: retitle -1 aptitude: [cmdline] impossible to select versions with search patterns
Control: tags -1 + confirmed
Control: retitle -2 aptitude: [cmdline] package, version selection is ad hoc, inconsistent
Control: severity -2 important
Control: tags -2 + confirmed

Hello

TL;DR: Search patterns on the command line never select specific
versions even though they can, this is by design.  There is no way to
specifically use the patterns' selected versions, nor is there any way
to select the installed or candidate versions of package without knowing
the version number (apt-utils have “=installed” and “=candidate”).  The
lack of that control is now tracked by this bug.

Your report also exposes that the way in which versions are selected is
ad hoc and inconsistent between commands.  This is a separate issue,
tracked by the clone.

> # aptitude search ~i~nmodule-init-tools
> i   module-init-tools  [description of 4.0.3-1 – the newest version]
> # # aptitude show ~i~nmodule-init-tools
> [details of 3.16-1 – the candidate version]
> # apt-cache policy module-init-tools
> module-init-tools:
>   Installed: 3.16-1
>   Candidate: 3.16-1
>   Version table:
>      4.0.3-1 0
>           1 http://rocky-mountain.csail.mit.edu/debian/ experimental/main i386 Packages
>  *** 3.16-1 0
>         500 http://rocky-mountain.csail.mit.edu/debian/ unstable/main i386 Packages
>         100 /var/lib/dpkg/status

Looks like APT::Default-Release is not set, good.  If it were the
situation would more complex. [1] That bug will absolutely be fixed in
the near future; my discussion here assumes so.

Also, the search pattern “~i~nmodule-init-tools” is not enough to select
only the installed version, for that you need “?narrow(~i,
~nmodule-init-tools)”.  See “Searches and versions” [2] in the manual
for the specifics of why that is.

So what happens if we use the proper version-specific search pattern
with these commands?  Search displays the details of the newest version,
yet show displays the the candidate.

Is it what you expect?  No, you expect to see details for the installed
version.

Is that a bug?  Yes! But not precisely what you think.  The only bug
here is that there is currently no way to say “show me the specific
versions selected by this search pattern.”

Why?

Because the install group of actions (including remove, purge, etc.)
can only ever act on a single version of a package which is determined
by the context (for example, remove acts on the installed version).
Even though the search pattern syntax is powerful enough to select
specific versions of a package it is practical on the command line to
ignore that – there are just too many complications trying to consider
them.

Now for some commands (such as show) it may actually make sense to use
the pattern-specific versions.  However, that makes those commands
inconsistent with the syntax of install, etc..

To overcome this, we use the same version tag syntax from apt-utils
(that is, “/ARCHIVE” and “=VERSION”).  Unless such a tag is present then
the version is determined by the command.  Most commands default to the
candidate version, some others use the installed version.  See the man
page.

I belive it makes sense to keep this behaviour.  With multi-arch it
becomes even more complex and using a similar restriction (that search
patterns do not select specific architectures, even though the syntax
supports this) is preferable. [3]

So the intended behaviour is that, regardless of the search pattern, if
you want a specific version you must use “=VERSION” or “/ARCHIVE”, and
if you want a specific architecture use “:ARCH”.  The specific case in
this bug report is unsupported by this.  With apt-utils, one can use
“=installed”, “=candidate”, and maybe some other syntax.

Finally (!) it does make sense to also have something like “=*” or
“=matched” to select the versions matched by the search pattern.
Likewise for architecture tags.  However there is a danger here because
a search “~nfoo” is matching all versions of the packages named foo, and
a command like “aptitude install ~nfoo=matched” is going to try
installing all those versions, resulting in error (which is why this
behaviour is absolutely not the default).

Regards

[1] http://bugs.debian.org/686316
[2] file:///usr/share/doc/aptitude/html/en/ch02s04s03.html
[3] http://bugs.debian.org/685731