Comment 30 for bug 831768

Thanks for the suggestions.

> [add search term "?architecture(amd64)", "~ramd64"]

This is done (development version). Also there is
'?multiarch(foreign)' etc.

'~r' is a reasonable choice for the short form. I had not
previously assigned one but will do.

> It should show results from all architectures because aptitude's
> search behavior(2) is very simple: if a package matches all of the
> terms, it matches the search pattern.

While this is "technically correct" behaviour, I wonder about it's
utility /on the command-line/. In particular, if a user has
lots of architectures configured (for cross-building or something)
then they will receive many duplicate results:

$ aptitude search pkfoo
i pkfoo
p pkfoo:armel
c pkfoo:mips
p pkfoo:mipsel
…

I have thought that the generic search (as above, without any
'?terms') should, by default, only return packages for the native arch
*and* any foreign-arch packages that are in some non-trivial state
(installed, config-files, etc.). For most packages, they are
available on every configured arch and the user is implicitly aware of
this. Listing each when they are in the not-present state is just
noise.

If a package is not available on the native arch then the first
foreign-arch version of it will be shown:

$ aptitude search only-for-mips
p only-for-mips:mips

If the user includes an '?archicture(..)' term (or perhaps any term?)
then that would override this behaviour.

Effectively, a search pattern without any '?architecture(..)' term
includes an implicit '?architecture(native-or-next-available)'.

> * Generally, the system should treat multiarch packages as single
> packages. Mainly because they are.

There are subtle differences.

For instance, dependencies vary. Binary packages for hurd-i386, for
example, depend on libc0.3; on freebsd-any they depend on libc0.1;
most other architectures will depend on libc6 *but* the version
required does vary, depending on the architecture.

I am not sure specifically what you mean by "treat multiarch packages
as single packages". Do you mean that, e.g., the interactive mode
of the program should only show each package once? This is possible,
by showing dependencies with arch-qualifiers ala packages.d.o:

  libc0.3 (>= 2.4) [hurd-i386]

There is further complication, that packages may not be updated in
lockstep (i.e. hurd-i386 has version 1.0 while amd64 has 2.0). Then
which should be considered the candidate version for installation?

This *could* be a configurable option, even the default behaviour.
However, it requires larger changes than simply having multi-arch
packages separated by architecture and so I will not be working on
this immediately.

> Multiarch packages should have a pseudo-architecture, "all".

Hi, what?

There is already Architecture: all. I don't understand what you
mean here. Multi-arch packages are of whatever architecture they
are for.

> Treating the multiarch packages as if they were multiple packages
> would cause confusion. I wouldn't want to even go in to that.

Disagree with you here, but then I'm not 100% sure what you meant in
the last two parts so need some clarification.

> * Aptitude should always default to installing the native architecture
> when no architecture is specified. This is obvious.

Yes. This is what happens even in 0.6.5-1 from the command-line; in
the curses interface you have no idea which architecture you are
looking at ;-)

> When displaying package names, aptitude should always print their
> architecture as well, in the format "<name>:<architecture>".

Following the lead of the core APT tools, the arch-qualifier
(":<arch>") is only shown for foreign-arch packages. This means that
users on non-multi-arch systems will not have the useless information
and, for users on multi-arch, it is easier to notice which package is
for the native-arch.

I consider it undesirable for aptitude to deviate from APT on this
point. However, having this configurable (e.g. "APT::FullName::Pretty-Print")
would be an excellent option.

> Perhaps there can be a switch in Aptitude that hides packages of
> foreign architectures when the same name packages exist for the local
> architecture.

Definitely. Synaptic leads the way here and already has such an
option.

> If multi-arch is disabled system-wide, then Aptitude should still
> display the full "<name>:<architecture>" format because there may
> still be foreign architecture packages installed.

Indeed, but only for foreign-arch packages. To do otherwise is
error-prone and confusing.