In https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/779174/comments/16, I presume you mean "apt-get update && apt-get dist-upgrade" for step 4, since "apt-get upgrade" won't install new packages or remove installed ones, and thus would often perform a partial upgrade producing a mixed Natty/Oneiric system of dubious functionality.
With that modification, and starting with a command-line only Natty system (freshly installed from the Natty i386 Alternate CD), I was able to reproduce the bug today. However, after running those commands, I then ran "apt-get dist-upgrade" again, and it was able to configure ca-certificates-java successfully. This workaround (of simply updating again, to trigger a re-attempt at configuring the package) had also worked on my fully-fledged graphical Oneiric system created by updating from Natty (that was the system on which I reported duplicate bug 779327) when the original fix for this bug was released. It also works when I create makeshift Oneiric live CD's by using the procedure at https://help.ubuntu.com/community/LiveCDCustomization and upgrading the live CD system's unpacked squashfs filesystem in the chroot (that is, in the chroot, ca-certificates-java initially fails to install, but when I run "apt-get upgrade" / "apt-get dist-upgrade" after the first attempt, it is installed/configured successfully).
That simple workaround has always been effective for me, but I'm not sure if it's effective in all cases. It would stand to reason that perhaps it's not, because if it is, then why have there been so many more sophisticated and cumbersome workarounds proposed here? If it is, then I think this should still be considered a bug needing fixing (packages are supposed to install correctly the first time), but perhaps its importance should be changed from Critical to Low. Or if it's important to document the bug it its original form as having Critical importance, perhaps this could be re-marked Fix Released and a new bug opened to document its new, more easily worked around form. That is, of course, assuming that it's as easily worked around on other systems as on mine, and for all I know, that might not be the case.
In https:/ /bugs.launchpad .net/ubuntu/ +source/ openjdk- 6/+bug/ 779174/ comments/ 16, I presume you mean "apt-get update && apt-get dist-upgrade" for step 4, since "apt-get upgrade" won't install new packages or remove installed ones, and thus would often perform a partial upgrade producing a mixed Natty/Oneiric system of dubious functionality.
With that modification, and starting with a command-line only Natty system (freshly installed from the Natty i386 Alternate CD), I was able to reproduce the bug today. However, after running those commands, I then ran "apt-get dist-upgrade" again, and it was able to configure ca-certificates -java successfully. This workaround (of simply updating again, to trigger a re-attempt at configuring the package) had also worked on my fully-fledged graphical Oneiric system created by updating from Natty (that was the system on which I reported duplicate bug 779327) when the original fix for this bug was released. It also works when I create makeshift Oneiric live CD's by using the procedure at https:/ /help.ubuntu. com/community/ LiveCDCustomiza tion and upgrading the live CD system's unpacked squashfs filesystem in the chroot (that is, in the chroot, ca-certificates -java initially fails to install, but when I run "apt-get upgrade" / "apt-get dist-upgrade" after the first attempt, it is installed/ configured successfully).
That simple workaround has always been effective for me, but I'm not sure if it's effective in all cases. It would stand to reason that perhaps it's not, because if it is, then why have there been so many more sophisticated and cumbersome workarounds proposed here? If it is, then I think this should still be considered a bug needing fixing (packages are supposed to install correctly the first time), but perhaps its importance should be changed from Critical to Low. Or if it's important to document the bug it its original form as having Critical importance, perhaps this could be re-marked Fix Released and a new bug opened to document its new, more easily worked around form. That is, of course, assuming that it's as easily worked around on other systems as on mine, and for all I know, that might not be the case.