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/statusLooks 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 <[email protected]> _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
