[Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled

[Daniel Hartwig]

> 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
Foundations Bugs, which is subscribed to aptitude in Ubuntu.
https://bugs.launchpad.net/bugs/831768

Title:
  aptitude cannot handle conflicts with multiarch enabled

Status in aptitude:
  Fix Committed
Status in “aptitude” package in Ubuntu:
  Triaged
Status in “aptitude” source package in Oneiric:
  Triaged
Status in “aptitude” source package in Precise:
  Triaged
Status in Baltix GNU/Linux:
  New
Status in “aptitude” package in Debian:
  Fix Committed

Bug description:
  TEST CASE:
  1. Enable multiarch (should be automatic on new oneiric systems)
  2. Install an i386 package on amd64 (like flashplugin-installer:i386)
  3. Mark something with a lot of dependencies for installation
  4. On the confirmation screen, try to remove on of the dependencies (aptitude will now fail to perform upgrades when there's a package conflict w/out removing the i386 libs)

  This renders aptitude painful on a multiarch enabled system (default
  in oneiric).

  ProblemType: Bug
  DistroRelease: Ubuntu 11.10
  Package: aptitude 0.6.4-1ubuntu2
  ProcVersionSignature: Ubuntu 3.0.0-9.12-generic 3.0.3
  Uname: Linux 3.0.0-9-generic x86_64
  Architecture: amd64
  Date: Tue Aug 23 00:28:38 2011
  ProcEnviron:
   PATH=(custom, no user)
   LANG=C
   SHELL=/bin/bash
  SourcePackage: aptitude
  UpgradeStatus: Upgraded to oneiric on 2011-03-06 (169 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/aptitude/+bug/831768/+subscriptions