Bug#676485: squeeze->wheezy dist-upgrade Could not perform immediate configuration on 'default-jre'
As I seem to be the bottleneck here lets see what I can do to help
remove this dependency as my "installability" is a bit flaky currently.
(what follows is myself rambling and jotting down what I did in the
hope that someone can make sense out of this some day.)
Before I start, I did all this in a squeeze to sid upgrade situation,
so your mileage may vary a bit …
The mentioned debug flags get us the following output at the end:
DepAdd FAILS on: libatk-wrapper-java-jni
DepAdd FAILS on: openjdk-6-jre
With the DepAdd lines above we can conclude which dependency of
libatk-wrapper-java-jni is the problem: libgdk-pixbuf2.0-0
(TODO: print that - you currently have to conclude this from the fact
that libcairo2 was the last successfully added dependency on that level)
What I usually do now is just removing dependencies from the
problem package and see what happens. Rinse repeat until you
found something which doesn't quiet "make sense".
"Unfortunately" this time you will soon find something big.
Usually it is just one, but this time all of them have to go:
Depends: libglib2.0-0 (>= 2.31.18)
Breaks: libgtk2.0-0 (<< 2.21.3), libgtk2.0-bin (<< 2.21.3), librsvg2-2
(<< 2.26.3-2)
So, okay, lets ignore the others and follow: libglib2.0-0
(after all, it is what all other packages have in common)
Play a bit and you will notice that killing
Breaks: eog (<< 3.2.2-3)
will free us from the problem. Okay, that seems to be something we
can work with. We move on and find
Depends: libexempi3 (>= 2.2.0)
so we follow this one:
Depends: libstdc++6 (>= 4.6)
Okay… (I see there this is heading)
Depends: gcc-4.7-base (= 4.7.2-4)
…
Breaks: gcj-4.4-base (<< 4.4.6-9~)
I knew it… We have reached a death-end here.
So lets see which old toys in squeeze depend on gcj-4.4-base and therefore
need to be upgraded now to remove this dependency.
That would be mostly "gcj-4.4-jre" which is a dependency of "gcj-jre".
So lets see, what holds back the upgrade:
Depends: gcj-4.7-jre (>= 4.7.2-1~)
…
Depends: libgcj13-awt (= 4.7.2-2)
…
Depends: libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.24.0),
libgtk2.0-0 (>= 2.24.0)
Here you go.
Nasty chain, but in the end APT should be able to break it, that it isn't is
a bug in APT/squeeze you need to workaround (seems to be less of a
breakage thing, it should "just" decide to do some things earlier.)
Okay, we get around with removing the 'eog' break – I really wonder why
libglib2.0-0 needs to break so many highlevel application packages
(it's a library for god's sake!), but I got no answer last time I asked gnome
people about this, so I guess it is as it is and must be …
Looks like the right moment to have a look at what APT/wheezy would
do in a situation like this. At least it finds a solution – looking at it
makes me cry like a little baby though. But even with wet eyes we can see that
eog is a package which is unpacked right after the "easy" essential packages –
easy as in e.g. coreutils – so we might be able to hint APT/squeeze into
doing eog earlier. It's not working with "easy" essentials, but what about
"hard" ones? Lets be crazy and try to add a Breaks: eog (<< 3.2.2-3)
to dpkg. And because it is so crazy, it actually works! (wot!)
You can make it work with other high-ranking dependencies which are actually
related like gconf2 which is a dependency of eog/squeeze so every eog user
should get the new gconf2, too.
So, here you have it, two possible workarounds, choose your poison or
find a better one of course. I just stop here because I ran out of time.
Looking at why we end up in this branch at all might be worthwhile e.g.
Bonushint:
$ apt-get dist-upgrade -o dir::state::status=./dpkg.status -c apt.conf
-y --force-yes
Is the command I used, apt.conf contains:
#clear DPkg::Pre-Invoke;
#clear DPkg::Post-Invoke;
#clear DPkg::Pre-Install-Pkgs;
#clear DPkg::Post-Install-Pkgs;
Debug::NoLocking "true";
Debug::pkgDpkgPm "true";
Debug::pkgPackageManager "true";
Debug::pkgOrderList "true";
Debug::pkgProblemResolver "true";
Debug::pkgAcqArchive::NoQueue "true";
#clear APT::Architectures;
APT::Architecture "amd64";
APT::Architectures:: "amd64";
APT::Install-Recommends "true";
Debug::pkgAcqArchive::NoQueue is a new option supported in APT/wheezy
which disables the download of deb files, which can be quiet handy in
situations like this. You can find the patch in rev. 2129.13.39.
This config should allow you to run apt-get as a user and out of a buildtree,
it's at least what I do (hence the revert of multiarch settings as APT/squeeze
has some "implementation differences" and you don't want to spoil your
experience with it …)
As you see, no black magic or voodoo involved.
Good luck,
David
Reply to: