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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
