Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 22 April 2013 20:30, Stephan Springer wrote: > Yes: See bug #954029. Trivial fix, could be SRU. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 22 April 2013 18:38, Stephan Springer wrote: > I checked by trying to install wine. The dependency resolution only > grumbles about one “recommends” which can't be resolved, which is > probably okay. gettext? -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 17 April 2013 17:25, Tim wrote: > Laney, pretty sure it was already fixed in Q,via upstream. Confirm this, with upstream hat on. The fix appears from version 0.6.8.1. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
[1] indicates to have a sponsor upload to -proposed before the Sru team will review. It states there is no need to wait. The package is unusable on m-a systems, in Ubuntu main, this upload is a self-contained fix: why you consider it so unsuitable? If the package does not get to -proposed, how else to bring this to sru teams attention? [1] https://wiki.ubuntu.com/StableReleaseUpdates#Procedure -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On Fri, Oct 05, 2012 at 09:08:34AM +0800, Daniel Hartwig wrote: > As someone familiar with the issue I request that you reopen those > tasks to their previous status and immediately assign them to cjwatson > (previously assigned) or someone else who is informed about this bug. Please don't assign these tasks to me. I won't have time to deal with them. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 4 October 2012 22:14, Michael Terry wrote: > So after some quick smoke tests of my own, I've uploaded it > to quantal. Appreciated. > According to comment 104, SRUs are not necessarily requested by this > bug. >From that comment, with emphasis added: > This is *currently* only a request to get the fixed > version (0.6.8.1) merged in Quantal. The SRUs are not requested yet as the fix [was] not in Quantal. That comment addresses the prior one regarding various SRU fields not being filled out and where the commenter appeared mislead by the status of the sponsoring overview (showing “SRU” instead of “merge”). > I will close the SRU tasks for precise and oneiric. I'm not sure > this would fit the definition of a good SRU candidate anyway. Not being sure about the candidacy should you rather leave it open to be adjusted by someone who is? Please confirm your action with the person who opened those tasks or one of the numerous @ubuntu.com people assigned and otherwise involved over the course of the bugs life.[1] As someone familiar with the issue I request that you reopen those tasks to their previous status and immediately assign them to cjwatson (previously assigned) or someone else who is informed about this bug. Such a person is in a better position to take the appropriate action(s) now required. Regards [1] CC to bring this back to their attention now that it is resolved. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 3 October 2012 03:27, YAFU <831...@bugs.launchpad.net> wrote: > Sorry, I've rushed. > Now "aptitude" v0.6.8.1 on Precise can not resolve dependencies when trying > to install Google Earth: > http://pastebin.com/eu2ua79c The proposed solution there looks fine to me, remove some -dev and misc. packages whose dependencies are being upgraded (and thus, no longer met). I'm sure one of the subsequent offerings will be to upgrade most of those packages instead. > > apt-get can install without problems. Please provide the typescript of apt-get for comparison. You should also skip through several solutions offered by aptitude so that we can see what is being considered—the order is some times not what the user expects. If you wish to pursue this as an issue file a new report as your experience is not that covered by this bug. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
Thanks everyone. I think we have enough user confirmations of the patch now. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 7 August 2012 13:44, Fyodor Kupchik <831...@bugs.launchpad.net> wrote: > After update went successfully I downloaded new skype package > from skype.com i386 version and installed it. Everything went OK! > > So here's is *definitely improvement* for me and disabling the > option in /etc/apt/apt.conf did the trick for me! > Thank you very much for your work! I'm now able to use aptitude > again! Thanks for the update. Anyone else using a workaround should be sure to disable it as well. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 6 August 2012 03:15, Edward Donovan wrote: > (I tried to build it against 0.6.8 from the debian source, but the gtest > stuff wouldn't build. I was compiling it with dpkg-buildpackage, and > couldn't find how to skip building those tests.) After review of the changes between .6 and .8, the patch should be fine on .6. Having said that, you can skip building the tests with the standard mechanism: $ export DEB_BUILD_OPTIONS="nocheck" $ dpkg-buildpackage … There is also a patch with Ubuntu specific changes for .8 attached to Bug #824708. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On Fri, Apr 27, 2012 at 8:09 AM, Daniel Hartwig <831...@bugs.launchpad.net> wrote: > Also, this report does not need more comments about: Sorry, Daniel. Overexcited about aptitude. :) -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 27 April 2012 11:12, Daniel Hartwig <831...@bugs.launchpad.net> wrote: > ** Description changed: > > 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 is not specific to multiarch. If you enable a repository with random conflicts with your current base system and install a package from such repository you get into this situation. Foreign arch on multiarch system is one of such possible repositories. Third party repositories often cause similar issues. > > This renders aptitude painful on a multiarch enabled system (default in > oneiric). on any system with complex dependencies. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On Apr 27, 2012 2:10 AM, "Edward Donovan" <831...@bugs.launchpad.net> wrote: > > I know this isn't a referendum, I just found these two cents in my > pocket. > > Shahar wrote: > > It's resolver is not so hot but to say that it "does not work" is a bit misleading! > > For what little it's worth, it looks that way to me, too. I can only > see that aptitude 'works' on a level it had not since multiarch began. > I have used aptitude for the great majority of its existence, about ten > years. Comparing the present Ubuntu package to those experiences: > > - I don't recall a time when the resolver worked much better for me, > than 0.6.6 does. I don't want to paper over the weaknesses of the > resolver, at all. I can't see that, with the recent multiarch patch, > they've regressed a lot from the time before multiarch. I don't have > test cases to offer, and anyone who does may trump my personal > experience. > > - Aptitude under multiarch was very broken for me; not really usable, > until the recent 0.6.6. > > - I now use it as I did in the past. It seems restored to the previous > level of functionality, for me, and I keep thinking "this is great, I > have aptitude back!" > > So perhaps someone will have a good wording to describe the situation > accurately. Acknowledge whatever clear regressions still exist, since > pre-multiarch. And convey that aptitude, in 12.04, works much, much > more than it did in the last few releases. If I had not been following > Precise all along, that is the information I would want to know. Great! Thank you, Edward! My thoughts exactly. > > I don't have a comprehensive picture of everyone's experience, of > course. This is just my attempt to contribute to it, and I have no > great complaint with the situation as it is. Thanks. > > -- > You received this bug notification because you are subscribed to the bug > report. > 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 -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 26 April 2012 20:35, Swâmi Petaramesh <831...@bugs.launchpad.net> wrote: > Well it was still broken yesterday evening ;-) > It's resolver is not so hot but to say that it "does not work" is a bit misleading! > > -- > You received this bug notification because you are subscribed to the bug > report. > 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 > -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 26 April 2012 18:37, Colin Watson wrote: > On Thu, Apr 26, 2012 at 03:05:20PM -, Shahar Or wrote: > > This is wrong! Aptitude works now! > > The logs of this bug are distinctly ambiguous on the subject :-) > I informed the release team about it. Thanks. > > -- > You received this bug notification because you are subscribed to the bug > report. > 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 > -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On Thu, Apr 26, 2012 at 03:05:20PM -, Shahar Or wrote: > This is wrong! Aptitude works now! The logs of this bug are distinctly ambiguous on the subject :-) -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 3 April 2012 23:12, Shahar Or wrote: > Dear Anders, Philip, Michal, Friends, > > I've filed individual bugs for the two issues that you mentioned, > Anders. > > Is there a "Well, the resolver is a mess." bug report :) ? Really, is > there? Launchpad or upstream Debian? Please give pointers if you have There is plenty of resolver issues reported in the Debian BTS. #432017 #346321 #391377 #495711 #502285 #519893 #570377 #579071 #588665 #594237 #619575 #632125 #637257 #651947 #659341 #186481 #209414 #213263 #248443 #251915 #252264 #325160 #330503 #333546 #338386 #341963 #342835 #344700 #348679 #359171 #359619 #365644 #375073 #385631 #417689 #419501 #428825 #437291 #444831 #446298 #448385 #453935 #457188 #462393 #464428 #465241 #478116 #480743 #484714 #486454 #488081 #490547 #497297 #498566 #498800 #501588 #501855 #502766 #508428 #509100 #512034 #514348 #516823 #536869 #537571 #537735 #529403 #540978 #541844 #542264 #548505 #555014 #555043 #555896 #556881 #559194 #559431 #561747 #564545 #565760 #566343 #567545 #569315 #570492 #574132 #574928 #575999 #576319 #579384 #587087 #590595 #590604 #591892 #598485 #599790 #610845 #612001 #613276 #615151 #631525 #637483 #638049 #639011 #641756 #643997 #644544 #648313 #649267 #651410 #655483 #658635 #658640 #663134 #663699 #618753 #661678 Note that while these are somehow related to resolving dependencies not all are actually in resolver. Still at least about half of them is. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On Mar 29, 2012 6:16 PM, "Stephan Springer" wrote: > > I tried to install aptitude_0.6.6-1_amd64.deb from debian/unstable today > on Precise, but that doesn't work because of a missing dependency to > libapt-pkg4.10, which is provided by apt 0.8.15.10 in Debian, but > installing that would be a downgrade from the Precise apt > 0.8.16~exp12ubuntu6. So I gave up. :( Thanks. Freeze exceptions require thorough QA, so we really need a package built. > > -- > You received this bug notification because you are subscribed to the bug > report. > 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 -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 13 March 2012 21:18, Daniel Hartwig <831...@bugs.launchpad.net> wrote: >> Sure, I'll file a request against APT. > > Never mind that. I will have a patch ready shortly. Thank you very much, Daniel! -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 13 March 2012 18:18, Daniel Hartwig <831...@bugs.launchpad.net> wrote: >> Packages from different architectures should definitely be displayed >> as individual packages because: >> ... > > That was my reasoning also. This is much easier to implement and > practically already done. Woohoo! >> 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. > > Configuration item to always show the ':' bit. When enabled you > will have both ':NATIVE' and ':all' displayed. > > Ideally, such an option will be implemented in APT and so also > respected by apt-get and others. Sure, I'll file a request against APT. What exactly do we want? I'm not familiar with APT configurations. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
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 ":" > > 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 ":" 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 13 March 2012 03:26, Daniel Hartwig <831...@bugs.launchpad.net> wrote: >> 3. each available architecture of packages that are available only in >> foreign architectures as ":" > > 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? The problem with showing separate archs separately is there is no easy way to list the packages then. In the ideal case they are at least in the same section (but may not if the section was changed and not all archs are rebuilt) but still some might be under new, another under installed, another under uninstalled, .. Showing the packages for different archs should be easier than searching all sections. Sure, you can change the way Aptitude organizes packages but there is no good UI for that. You have to manually type in the properties by which the packages should be categorized. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 10 March 2012 06:20, Daniel Hartwig <831...@bugs.launchpad.net> wrote: > '~r' is a reasonable choice for the short form. I had not > previously assigned one but will do. Great! >> It should show results from all architectures because aptitude's >> search behavior(2) is very simple: if a package matches all of the >> terms, it matches the search pattern. > > While this is "technically correct" behaviour, I wonder about it's > utility /on the command-line/. In particular, if a user has > lots of architectures configured (for cross-building or something) > then they will receive many duplicate results: > > $ aptitude search pkfoo > i pkfoo > p pkfoo:armel > c pkfoo:mips > p pkfoo:mipsel > … > > I have thought that the generic search (as above, without any > '?terms') should, by default, only return packages for the native arch > *and* any foreign-arch packages that are in some non-trivial state > (installed, config-files, etc.). For most packages, they are > available on every configured arch and the user is implicitly aware of > this. Listing each when they are in the not-present state is just > noise. > > If a package is not available on the native arch then the first > foreign-arch version of it will be shown: > > $ aptitude search only-for-mips > p only-for-mips:mips > > If the user includes an '?archicture(..)' term (or perhaps any term?) > then that would override this behaviour. > > Effectively, a search pattern without any '?architecture(..)' term > includes an implicit '?architecture(native-or-next-available)'. We do want to make the search results as humanly readable as possible while keeping it obvious to understand. We should do this by assuming that most users prefer native architectures and would like to see what's installed, has configuration files or is broken (these three are the non-trivial states, right?). So an aptitude search without ?terms() should print: 1. packages that are available in the native architecture as "" 2. multi-arch packages as ":all" 3. each available architecture of packages that are available only in foreign architectures as ":" 4. foreign architecture packages that are in non-trivial states as ":" This should be called "?architecture(prefer-native)". So the difference between this and the "?architecture(native-or-next-available)" term value is that it would show all architecture packages and not only the first foreign architecture package. 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. # so for example $ dpkg --print-architecture amd64 $ aptitude search foo p foobar # no architecture suffix because native p foo-common:all # multi-arch p foo-mips:mips # only in foreign architectures... p foo-mips:mipsel # so printing all of them p food # same as foobar i food:i386 # installed and foreign c food:mips # configuration files present and foreign This defaulting to an "?architecture(prefer-native)" filter in command-line search is a preference of convenience over consistency. To prevent any trouble, whenever a search includes any search term, like "?action()", "?section()" or anything else, this Chutzpah filtering is GONE and the default behavior of printing matches of all available architectures, one by one, is assumed. >> * Generally, the system should treat multiarch packages as single >> packages. Mainly because they are. > > There are subtle differences. > > For instance, dependencies vary. Binary packages for hurd-i386, for > example, depend on libc0.3; on freebsd-any they depend on libc0.1; > most other architectures will depend on libc6 *but* the version > required does vary, depending on the architecture. > > I am not sure specifically what you mean by "treat multiarch packages > as single packages". Do you mean that, e.g., the interactive mode > of the program should only show each package once? This is possible, > by showing dependencies with arch-qualifiers ala packages.d.o: > > libc0.3 (>= 2.4) [hurd-i386] 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? Why should multi-arch packages be considered multiple packages? > There is further complication, that packages may not be updated in > lockstep (i.e. hurd-i386 has version 1.0 while amd64 has 2.0). Then > which should be considered the candidate version for installation? > > > This *could* be a configurable option, even the default behaviour. > However, it requires larger changes than simply having multi-arch > packages separated by architecture and so I will not be working on > this immediately. > > >> Multiarch packages should have a pseudo-architecture, "all". > > Hi, what? > > There is already Architecture: all. I don't understand what you > mean here. Multi-arch packages are
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
>> Now that aptitude understands multiarch packages you should not get >> bazillions of errors. >> > > Have you been using the in-development version and noticed less > errors, or is this just speculation? No, I don't see the in-development version packaged anywhere. However, this is more than just speculation. Obviously, many of the errors are caused by aptitude's inability to tell apart package:i386 and package:amd64 which should by fixed now. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
On 10 March 2012 05:49, Daniel Hartwig <831...@bugs.launchpad.net> wrote: > Hi Michal (hramrach) > >> Any possible multiarch-specific issues will be lost in the >> heaps of issues the resolver already has. >> > > Some do stand out quite harshly. Consider #651748 [1] where the UI > is trashed by multi-arch related error messages from the resolver. > This is non-fatal but still a serious blocker. Is this multiarch specific? IIRC I got this noise way before multiarch, there was just way less noise before there were packages aptitude does not understand. Now that aptitude understands multiarch packages you should not get bazillions of errors. Sure, it's still potential problem that there is no rate limit on these messages or anything but it's no longer likely that you will not see any UI at all due to messages rolling all over your screens constantly. -- 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
Re: [Bug 831768] Re: aptitude cannot handle conflicts with multiarch enabled
Hello, thanks for bringing these fixes. >From my view these are probably enough to make aptitude "support multiarch". As for resolver being unreliable on multiarch - I don't consider that a multiarch issue. It is a long-standing problem that the resolver is generally unreliable. Any possible multiarch-specific issues will be lost in the heaps of issues the resolver already has. The value I see in aptitude is an interactive UI for exploring packages and their dependencies which should be restored once aptitude can deal with packages of multiple architectures sanely. -- 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
