Hi, On Sat, Apr 06, 2013 at 04:37:51PM +0200, Toni Mueller wrote: ... > > > For you, they were co-installable eventually for you? I could not do > > > this here too initially. When I tried first, it caused major package > > > removal situation. > > I was struggling with this as well, and that led to my initial bug > report. As I wrote, trying to co-install these, and other relevant, > packages is quite a bit of a hit-and-miss experience. I think this > should be a limitation in apt and aptitude. What I did to co-install > these packages, was to actually download the packages individually, then > installing them like this: > > # dpkg -i pkg1 pkg2 pkg3 ... > > Please note that this is neither an acceptable solution for the average > end user, nor is it straightforward: You have to co-install all relevant > packages in one go, otherwise, you'll end up with eg. only the i386 > versions of it, or whichever version you specified last.
I agree. Downgrade dependency handling for multiarch should be better. > > I haven't tried myself, but if they aren't co-installable then it > > reveals some packaging mistakes. > > As things currently stand, it looks like these packages are > co-installable, just not via apt or aptitude. That is another indication package dependency resolution is the cause of trouble. > > > with some dependency packages. If that was caused by packages from > > > unstable, I downgraded to testing ones. > > > > > > Then I was still stack with libgdk-pixbuf2.0-0 and libgtk2.0-0. > > > Tracing this goes to libjasper. Here libjasper1 (!= 1.900.1-13) but I > > > have 1.900.1-14 > > $ dpkg -l libgdk-pixbuf2.0-0 libgtk2.0-0 libjasper1 > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture > +++-====================================-=======================-============ > ii libgdk-pixbuf2.0-0:amd64 2.26.1-1 amd64 > ii libgdk-pixbuf2.0-0:i386 2.26.1-1 i386 > ii libgtk2.0-0:amd64 2.24.10-2 amd64 > ii libgtk2.0-0:i386 2.24.10-2 i386 > ii libjasper1:amd64 1.900.1-13 amd64 > ii libjasper1:i386 1.900.1-13 i386 > > libjasper1 1.900.1-14 is in unstable, not in testing. For you case of experimental and unstable mixture, issue may be slightly different in terms of exact version. What are "apt-cache policy ..." for these? > > > OK downgrade libjasper1. Similarly downgrade libcolord1 for ibus-gtk3. > > $ dpkg -l libcolord1 ibus-gtk3 > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture > +++-====================================-=======================-============ > ii ibus-gtk3:amd64 1.5.1.is.1.4.2-1 amd64 > ii ibus-gtk3:i386 1.5.1.is.1.4.2-1 i386 > ii libcolord1:amd64 0.1.21-1 amd64 > > Maybe I have a problem there, with libcolord1... If you used dpkg libcolord1:i386 required by libgtk-3-0:i386 may be missing. > > > Anyway, you need to be careful for this kind of downgrade resolution > > > problem if you are running mixed system. > > Yes. I've written a script to download packages at specific versions to have > the same versions for both architectures. Otherwise, if the versions differ, > dpkg refuses to install anything. But I had to use --force-overwrite plenty > of times, anyway. OOps, that is risky. This is the cause of you missing libcolord1:i386. Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
