On 13 March 2012 04:26, Daniel Hartwig <email address hidden> wrote:
>> 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.

Thanks, Got it.

> 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/*).

Thank you!

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

Packages from different architectures should definitely be displayed
as individual packages because:
1. They are individual packages. Unlike different package versions,
these can be installed simultaneously. That's the difference.
2. Would be far better to not have to go into the package detail
screen to see available architectures. This is more practical, more
productive, etc. . I can imagine it being a nightmare to have to go
into package details to see about the availability of architectures
and in the worst case when a dependency issue (as soon as the resolver
is able to do that) arises. Rather, they should be listed with the
"<name>:<architecture>" format because that would promote the mental
sanity of our users. Of course, there's the
"?architecture(prefer-native)" that we talked about, which can be used
to make the lists even more sane and that it should be in the default
view. Of course, this argument can be individual so while I suspect
that I speak for most users of Aptitude curses interface, it would be
nice to have another opinion.
3. This is to be consistent with the results in the command-line
"aptitude search". It can't be reasonable to display multiple
architectures one way on the command line search and another on the
curses interface, can it?

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

Yes, I apologize. You understood my mistake, calling "Architecture:
all" packages "multi-arch" packages. We can call them neutral
architecture packages :) . It may catch on.

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

Can you show me an example, please?

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

OK, I think that this desirable behavior because usually native
architecture packages and neutral (if you don't mind :) ) architecture
packages are practically the same thing for users.

What if I care? What if I want to see, in a search result or a
filtered view, both native and neutral architecture packages and to be
able to tell them apart from each other? Treating the neutral ones as
if they were native ones should be a deault - like
?architecture(prefer-native) is - not a constraint.