Bug#645713: fails to upgrade a default GNOME desktop installation from squeeze → sid
On Thu, Apr 4, 2013 at 10:46 PM, Julien Cristau <jcristau@debian.org> wrote:
> On Sun, Mar 24, 2013 at 18:17:46 +0100, David Kalnischkies wrote:
>
>> Pictures^Wdpkg-status files or it didn't happen, as I said multiple times now.
>>
> You'll find the (compressed) status file attached.
[…]
> E: Could not perform immediate configuration on 'openjdk-6-jre'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
Thanks.
After wasting a few days on this now I know at least who is at fault: me.
And as I am not a dependency I pass the blame on to Java5 and OpenOffice.
[I will spare you the details now, you will find some below as very long P.S.]
I have done very few tests, but it seems like bringing openoffice.org-core
back (as a transitional package) is the simplest workaround. If I remember
right all status-files I have seen so far about this issue (not that many,
but yeah) included openoffice (as I wondered why it was touched so early
and wanted to investigate this after wheezy), so while this sounds indeed
crazy I guess it would solve all known issues. Hence CC'ing the previous
maintainers to gaining some intelligence on how feasible this is.
(Such a transition package needs to break at least
"openoffice.org-report-builder-bin" as it is otherwise not removed
on upgrade. I have no idea what else / how depends should look like)
Alternatively we could provide a "fixed" apt/squeeze which removes the most
offending lines (and reopens bugs), but the usual problems arise from that.
Best regards
David Kalnischkies, who works on a timemachine now to travel ~3 years into
the past to prevent a certain someone from committing something harmful …
(… and ~10 more to prevent the other half by various others).
P.S.:
I mentioned the Provides change earlier which after carefully looking at it
breaks now after 3 years into pieces and I wonder how it worked at all …
(not that the code before that would be bug-free, I just "enhanced" it)
Describing whats going on is a bit hard and frankly I haven't worked out
myself in completion what the code does, just what it should do and while
this overlaps at many points, in edgecases the code runs amok …
This code is run for all dependencies effected by a remove, but a problem
will only arise if you have an or-group somewhere behind that dependency
which features virtual packages AND [pretty freaky ordering conditions –
I will refer to it as "magic"].
In the "testcase" we happen to meet these conditions once: While removing
openoffice.org-core we call this code for many openoffice.org-* packages
one of those is "openoffice.org-officebean" which features such a magic
or-group beginning with "default-jre | …". The "magic" will help us skipping
over most of the or-group, but we will end-up with "java5-runtime" being
mistakenly chosen for immediate promotion to a package needing immediate
configuration (better: a provider as java5 is virtual).
So we end up with stuff like 'openjdk6-jre' as "kinda pseudo essential".
(I am positive that it "works" with other openoffice.org-* packages too,
as long as they need the core package and java [in that order], which is
true in the example for "openoffice.org-base", too – and it works with
promoting others like gcj-jre, too. Which one is chosen exactly depends on
magic, just like promotions in real life do [SCNR]).
That these packages become "kinda pseudo essential" is a bug, but in most
cases apt/squeeze can work with that. Sometimes it can't, which is a "known"
bug [hopefully] fixed in apt/wheezy which I suspected as being at fault here
as the usual symptoms apply (and disappear with apt/wheezy).
I am working for a while now on fixing this code, which basically means
a complete rewrite of the DepRemove method, but as usually the bug leads just
to a non-optimal ordering, we could (and I tend to should) "happily" delay
this until jessie and work around it as we usually do it with bugs in APT.
P.P.S.: The "Conf Broken" error(s) can be ignored as they just happen in
simulation. In the real run APT will tell dpkg to "do the right thing™" and
it usually does (like configuring two packages "at the same time").
Reply to: