Comment 38 for bug 831768

On 10 March 2012 06:20, Daniel Hartwig <email address hidden> wrote:
> '~r' is a reasonable choice for the short form.  I had not
> previously assigned one but will do.

Great!

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

We do want to make the search results as humanly readable as possible
while keeping it obvious to understand.

We should do this by assuming that most users prefer native
architectures and would like to see what's installed, has
configuration files or is broken (these three are the non-trivial
states, right?).

So an aptitude search without ?terms() should print:
1. packages that are available in the native architecture as "<name>"
2. multi-arch packages as "<name>:all"
3. each available architecture of packages that are available only in
foreign architectures as "<name>:<architecture>"
4. foreign architecture packages that are in non-trivial states as
"<name>:<architecture>"

This should be called "?architecture(prefer-native)".

So the difference between this and the
"?architecture(native-or-next-available)" term value is that it would
show all architecture packages and not only the first foreign
architecture package. The reason for this is that the order in which
they are specified in the /etc/dpkg/dpkg.conf.d/multiarch is not an
order of preference.

# so for example
$ dpkg --print-architecture
amd64
$ aptitude search foo
p foobar # no architecture suffix because native
p foo-common:all # multi-arch
p foo-mips:mips # only in foreign architectures...
p foo-mips:mipsel # so printing all of them
p food # same as foobar
i food:i386 # installed and foreign
c food:mips # configuration files present and foreign

This defaulting to an "?architecture(prefer-native)" filter in
command-line search is a preference of convenience over consistency.
To prevent any trouble, whenever a search includes any search term,
like "?action()", "?section()" or anything else, this Chutzpah
filtering is GONE and the default behavior of printing matches of all
available architectures, one by one, is assumed.

>> * 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]

Dear Daniel, you said "- consider how the system in general should
treat multiarch packages (consider them a single, or multiple
packages? What are the pros and cons of each approach?)"

Can you please elaborate on that question? Why should multi-arch
packages be considered multiple packages?

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

Yes, I am talking about packages that are for all the architectures:

$ apt-cache show apache2-doc | grep Arch
Architecture: all

I knew that this was already in place when I wrote that. I apologise
for the confusion.

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

I'm also not 100% sure what you meant with that, above.

>> * 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 ;-)

About the curses interface, which actually lives up to it's name now
;-), once it can display the "<name>:<architecture>" format,
"?architecture(prefer-native)" should be added to it's default view
filter. This way we get comfortable results and also it is obvious
that this filtering is taking effect so it is less Chutzpah.

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

Yes, this is an excellent idea. As long as Architecture:all packages
are printed with the ":all" suffix, to differentiate them from the
native arch packages.

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