On 13 March 2012 04:26, Daniel Hartwig <831...@bugs.launchpad.net> 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. -- 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
