[Aptitude-devel] Bug#687474: aptitude: [cmdline] package, version selection is ad hoc, inconsistent

[Daniel Hartwig]

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