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

[Manuel A. Fernandez Montecelo]

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


2012-09-13 06:20 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]

In the bug reports leading to this, and others such as #539978, there is
an underlying complaint that "show" uses the candidate instead of the
installed version (or that other tools don't do what "show" does).

So I wouldn't say that it's the "universal sensible" thing to do.

Also, changelog downloading the candidate instead of the current can
lead to confusions.  I think that it's probably better to have candidate
than current in the case of changelog, but again, I wouldn't be
surprised to receive bugs asking for the contrary.


>For no good reason some commands will accept search patterns in place of
>package arguments (such as show) while others will not (changelog).

One good reason is that if "changelog" accepts patterns and one makes
mistakes and doesn't pay attention for some reason (e.g. gets
distracted), the user ends up downloading many MBs of package
changelogs, or launching many separate processes at once (e.g. a fork
bomb), depending on the robustness of the implementation or arbitrary
limits set.

And because changelog with one argument it's generally good for 99.9% of
cases.


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

Except that it does not:

  aptitude [<options>...] {why | why-not} [<patterns>...] <package>
  ...
  If one or more <pattern>s are present (in addition to the mandatory
  last argument, which should be a valid <package> name), then aptitude
  will begin its search at these patterns. [...]


>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

I find this kind of rambling in several related reports particularly
time consuming when triaging bug reports many years later, when one has
to spend many minutes just to go through this kind of stuff to get to
the core of the matter.

Also, repurposing a very remotely related report for all of this,
instead of just submitting a new report with two or three paragraphs
explaining the (very concrete) thing that it's proposed in the end, only
serves to waste time.


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

Many of the exit status problems were fixed in the 0.7 series, which are
unrelated, and the "serious errors which can easily leave a system in a
crazy or broken state" are also completely unrelated to the problem of
this report ("package, version selection is ad hoc, inconsistent").


>There is no reason to maintain this historical inconsistency, which is
>unmanageable and matches neither user expectations or the documentation.

Indeed, there is no reason to maintain this historical inconsistency.

But since the alternative was never implemented, this is what we're left
with.


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

This might be an idea, at long last.  It's probably
PackageContainerInterface, not PackageSet, but well.

However, having this idea open for many years marked as "important" did
not lead to the underlying problems listed being fixed.  Some were fixed
for other reasons and by other means other than the ones explained here.

If somebody wants to improve the inconsistencies listed, it's easy to
know how to start, IMO no extra insight will be obtained by reading
this.


So, for all the reasons above, I don't think that this report is very
useful to keep open... thus closing now.

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