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 <mbe...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
