> 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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/831768
Title:
aptitude cannot handle conflicts with multiarch enabled
To manage notifications about this bug go to:
https://bugs.launchpad.net/aptitude/+bug/831768/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
