[Aptitude-devel] Bug#687888: usability: shouldn't list each arch as a separate package

[Daniel Hartwig]

Control: severity -1 wishlist
Control: tags -1 + confirmed help
Control: tags 673099 + help
Control: merge -1 673099

Hello

[Using wishlist since aptitude uses the same model as APT and this is
not a bug.]

The current multi-arch support in aptitude has the goals of
simplicity, compatibility with apt-utils, compatibility with the
multi-arch specification, and not hiding details of the internal APT
model via aggregation of packages.  As a long as this is a direct
reflection of the model internal APT this design will remain.

Help is certainly welcome to design and implement an alternative
support for multi-arch as an optional addition to the current support.

On 17 September 2012 02:56, Michael Below <mbelow at antithese.de> wrote:
> since I added the i386 arch to my amd64 setup, the package list in
> aptitude nearly doubled in length: there are two entries for each
> binary package, one amd64, one i386.

To APT they are separate binary packages.

> Arch is treated as a part of
> the package name.

This is compatible with apt-utils.  How else do you propose to specify
a package:arch combination?

> This is impractical when scrolling through the list. This gets
> worse if more architectures are installed.

You can limit the display (“l”) with “~r$arch” if the length bothers you.

> I think aptitude needs another dimension in its user interface,
> besides package names and package versions. There should be
> another column for available architectures (if there are more than
> one) instead of treating it like a part of the package name.

Yes indeed.  However I am reluctant to implement this most simple
aggregation because there are various ways in which multi-arch
packages interact with each other and at the time it was non-obvious
what to do.  I am yet to be made aware of any practical and detailed
design for a more advanced multi-arch interface.

For the case of Multi-Arch: foreign I think your suggestion works
fine.  The architectures are equivalent to how to versions are
currently treated and there is no ambiguity of loss of information in
aggregating.

What about Multi-Arch: same, allowed, none?  It does not work so
simply there.  Although the details could somewhat be aggregated, it
is *not* equivalent to version aggregation.  For m-a-same package
installed on only one architecture, what is it's status?  When it is
installed on more than one, what then?

Further, as soon as aptitude begins to aggregate multiple packages and
their states together it has left the realm of directly conveying the
APT model and started to produce it's own concept of “packages” which
is not related to anything in the APT database.  If other frontends do
this also there are potentially many different ideas of “packages”
between interfaces with at best a minimal consistency.

In general, frontends should refrain from displaying concepts other
than what APT presents them.  Although aptitude could experiment with
such features they should be eventually implemented within APT.

I look forward to reading your detailed design.