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

[Manuel A. Fernandez Montecelo]

Control: severity -1 wishlist
Control: tags -1 - confirmed
Control: owner -1 !
Control: close -1


2012-09-13 05:05 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.

?narrow doesn't make any difference in this case, I think.
'?narrow(~n^apt$, ~Aexperimental)~ramd64' continues to show the version
from experimental, same as if ?narrow is not used.

"aptitude versions" shows the same in both cases:

  $ aptitude versions '?narrow(~n^apt$, ~Aexperimental)~ramd64'
  Package apt:
  p   1.3~exp1              experimental                   1

  $ aptitude versions '~n^apt$~Aexperimental~ramd64'
  Package apt:
  p   1.3~exp1              experimental                   1

So I don't know if this worked differently at some point, but it works
as expected now (also tested this later with other bug reports, not only
this case).


>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.

This is debatable, different people expect different things, and even
same people expect different things at different times.  There's also
the somehow related #539978 for show, now closed.

"search" only shows one version at a given time, so it cannot work if
one user expects to see the "current" and another the "candidate".

That's probably the main purpose of "versions", though, which lists the
different versions and tells which one is (or are, in multi-arch)
installed, so duplicating functionality and rendering "versions"
redundant is IMO undesirable and we already have too much of that.


>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.”

So then it's not a bug, at most a whishlist to change the existing and
documented behaviour.

(In the case of show, it shows the "candidate" version, enhanced with
"currently installed, upgradable" for bugs like the mentioned #539978).


>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..

(Now, the complaint was about "search", not "show", so all of this is
unrelated).


>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.

"show" also has -v, showing info about all versions at the same time.
So one can easily do this and then look at the info of what one is
interested in, if it's to inconvenient to type the shortish:

  $ aptitude show module-init-tools/unstable


>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).

I don't really see why it "makes sense" to do that, especially with:

- all the complications mentioned,

- given that nobody asked about this in the long list of hundreds of
  bugs triaged over the last few years (not even the original reporter,
  since this doesn't address the example),

- this bug not having seen any secondings after the reformulation,

- and no real actions taken towards this since the formulation

So closing.

-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>