+++ Phil Endecott [2016-05-14 00:42 +0100]: > Dear Experts, > > In my ODROID-C2 thread, I mentioned that I was going to try to > set the system up to use arm64 by default but to support armhf > for those packages that are missing or buggy on arm64. I've not > been very successful with this so far. > > Based on some suggestions on the ODROID forum, I have installed > an arm64 base system - which works well. I have then: > > # dpkg --add-architecture armhf > # apt-get update > # apt-get install libc6:armhf > > Now I try to install abiword, which doesn't exist for arm64 (at least > it doesn't in jessie):
Yes. Abiword was not built for arm64 in jessie due to some missing dependency - I forget which. > # apt-get install abiword:armhf > Some packages could not be installed. > So, what I expect you have is a 'something is not multiarched' issue. But it can be tricky to work out what. > Hmmm. I experiment by trying to install the first dependency, > libabiword-3.0:armhf; It is generally best to start at the bottom of the list of 'X won't be installed' and keep following whatever is listed last. This will usually get you to the actual package at issue, but sometimes it's just complicated and not obvious. Using aptitude (in curses mode) i.e just 'aptitude' is often informative when trying to work out what on earth is up. > I get a similar message with a further list of dependencies. I try > installing its > first dependency, and so on: > > libchamplain-0.12-0:armhf > libclutter-1.0-0:armhf > libgtk-3-0:armhf > librest-0.7-0:armhf > libsoup-gnome2.4-1:armhf > libsoup2.4-1:armhf > glib-networking:armhf > libproxy1:armhf > > Finally libproxy1:armhf doesn't give an error, but luckily I used -s because > it wanted to remove half of the system: Right. It's quicker starting at the bottom of the list. > > I get similar results with other packages. > > Hopefully, I've missed some simple step needed to make this work. No, what are doing is the right thing and 'should' work, but does not necessarily work for any random package as all the package's dependencies have to be 'multiarch-installable' for things to work. > Or possibly, this is all stuff that has been fixed post jessie. It is certainly likely to be better. A load more stuff has been fixed (and of course you can just install abiword:arm64 so the issue may not arise) > Any suggestions would be much appreciated. There are a couple above (Use testing, try aptitude). What I don't understand is what the actual problem is. libproxy1 is multiarch:same and exists in matching versions between arches, and so is libstdc++6, so they should install without wanting to remove most of your system. There is clearly a conflict there somewhere. Try them individually to see which one is doing this. One possibility is version-skew due to binNMUs. If something is rebuilt on one arch but not another, dpkg considers them not multiarch-equivalent. This is annoying and there was quite a lot of it in jessie (depsite my efforts to sync rebuilds across arches so at least the core didn't have this problem). I think this is fixed in Stretch. Aha. yes this is it: $ apt-cache show libproxy1:arm64 Package: libproxy1 Source: libproxy (0.4.11-4) Version: 0.4.11-4+b3 $ apt-cache show libproxy1:armhf Package: libproxy1 Source: libproxy (0.4.11-4) Version: 0.4.11-4+b2 The versions don't match. So they are not co-installable (even though they almost certainly are really). This sucks (I did a load of rebuilds to minimise this issue before jessie was released but got told off by release managers after a while so had to stop). If you rebuild your libproxy for arm64 locally to have +b2 instead of +b3 and install that, maybe everything will work. Using a backported newer dpkg may also meanthe problem goes away (I forget if this fix has gone in or not). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
signature.asc
Description: Digital signature
