[Aptitude-devel] Bug#823927: aptitude: MultiArch searching beeps the terminal

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending
Control: found -1 aptitude/0.6.8.2-1


Hi,

2016-05-10 14:57 Vincent Lefevre:
>Package: aptitude
>Version: 0.8.1-1
>Severity: minor
>
>I get (visual) beeps in my terminal when searching for MultiArch
>packages. For instance, if I type /libwine:i386 I get a beep for
>the characters ":", "i", "3" and "8", which is annoying.

After a couple of hours investigating this, this seems to be due to the
change:

  https://anonscm.debian.org/cgit/aptitude/aptitude.git/commit/?id=d78de1ea77ad1c48b993c303628a133a3001f465

... and the fact that the Incremental Search is enabled (it is by
default).

For example, this allows to search for aptitude:any, and in multi-arch
amd64+i386 it will show:

 $ aptitude -w 80 search aptitude:any
 i   aptitude                        - terminal-based package manager
 p   aptitude:i386                   - terminal-based package manager

The same search in TUI will jump to either of those packages (whichever
comes first), and typing 'n' after the first match would jump to the
other one, and so forth.

In other words, the string has special meanings like linux-any or
any-i386, as defined in policy (11.1 Architecture specification
strings), and aptitude accounts for this (defers the comparison to
libapt).  It also supports :native and :foreign.

The change above has the side effect that the strings for the arch
search pattern are no longer treated as simple "string patterns" as it
happened before, when architectures were matched with partial strings
(as it does with package names, etc.).  And in the case of TUI with
interactive search enabled, it means that packages do not match until
the arch-specification is complete/valid, triggering the "beeps".


The last two Debian stable releases contain these changes, so it's too
late to simply revert (even if it was a good idea); and the change has
been present for close to 4 years without complaints until now.

It would be a bit of a mess and would need to have complicated rules to
try to decide if a string such as '*a*' should match arm64 and amd64, or
also OSs named with that pattern, and also linux-any or any-"cpu" (since
"any" matches "*a*"), or "native".

So I think that the best solution now is to change the documentation to
better reflect this behaviour, and not change the current
implementation.


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