Comment 39 for bug 831768

> 3. each available architecture of packages that are available only in
> foreign architectures as "<name>:<architecture>"

Ok, this may prove more useful than what I was considering (only show the first such architecture).

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

Dpkg does not care about the order of architectures because it only deals with exactly the packages it is instructed to.

On the APT level a prefered order is needed. APT::Architectures is the configuration item that defines this (/etc/apt/apt.conf or /etc/apt/apt.conf.d/*).

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

Things like, should the package view be grouped by architecture?

--\ Installed Packages
  --\ armel
    --- admin
    ...
  --\ powerpc
    --- admin
    ...

Or should each package only be shown once (just the name) and
have the different available architectures elaborated on the
package info screen?

> Why should multi-arch
> packages be considered multiple packages?

To be clear, when I say 'multi-arch packages' I am refering to packages which implement the multi-arch spec[2] -- not packages which are 'Architecture: all'. I am not sure if you mean the same thing here, since you keep refering to multi-arch packages being displayed as "pkg:all".

The reason they might be considered separate packages is because they are. Anything else is just a (potential) convenience to the user.

foo:armel, foo:powerpc, foo:amd64 are all distinct packages which just happen to share the same name. There are many differences between them that make each unique.

[2] http://wiki.ubuntu.com/MultiarchSpec

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

I meant that I was confused about the last two parts of your post because it seemed like you were refering to "multi-arch packages" as being equivalent to "architecture: all".

The part I disagree with is that treating multi-arch packages as multiple packages would cause confusion.

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

"apache-doc:all" would be deviating from APT, which shows "apache-doc".

Also, 'Architecture: all' is always a native architecture.