Control: block -1 by 686316 Control: owner -1 ! Each command line action implements it's own logic for converting arguments to sets of packages and/or versions. This not only represents a lot of duplication but also is the cause of many inconsistencies, user frustration, and a not insignificant amount of bug reports.
Compare the main entry points of each file under src/cmdline. In versions up to and including 0.6.8.1, for example, APT::Default-Release will take precendence over any candidate version (as determined by apt_preferences(5)) on *some* commands but not others (broken: changelog, download, show). The sensible and *documented* behaviour of those commands is to select the candidate by default. [1] For no good reason some commands will accept search patterns in place of package arguments (such as show) while others will not (changelog). The exception here is why (and why-not) which absolutely must have exactly one package identified by it's final argument – that *is* a good reason to not accept a search pattern for that argument. Some commands only treat text containing either “~” or “?” as a search pattern while others consider any text which does not exactly name a package to be a pattern. With a command line interface which appears very similar to apt-utils, the behaviour of package selection in aptitude should extend the base behaviour demonstrated by apt-utils (and other APT frontends). This is not the case! Aptitude commands do not accept straight regex expressions (“gnome-.*”) where apt-utils do. Heck, the search pattern syntax even supports regex matching, but only if the particular command maybe supports it *and* it explicitly uses the search pattern syntax of “~ngnome-.*”. Only one aptitude command accepts the “some-task^” syntax, standard in the apt-utils interface. Maybe I want to show all packages which belong to a task? What was the search term for that again, “?task(^some-task$)”? (Not so important for Debian now that tasksel is using task metapackages, however other types of tasks exist.) The list goes on. Hello This situation is ridiculous. Really. I am not even talking about the gross handling (or non-handling) of serious errors which can easily leave a system in a crazy or broken state. There are already many bug reports for that. There is no reason to maintain this historical inconsistency, which is unmanageable and matches neither user expectations or the documentation. There is now PackageSet and VersionSet in libapt-pkg which have constructors for command line arguments. These provide the standard apt-utils semantics and can be readily extended to support aptitude's pattern matching on top of that. Use these and the intra- and inter-package inconsistency with aptitude disappears along with many bug reports, both extant and yet-to-be-filed, and so much user frustration. Amazing. [1] http://bugs.debian.org/686316 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
