I have one:

1) Display a big bold red message on the user's console or package manager explaining what is happening.

2) Offer to install openJDK as a default action.

3) Profit ?

Once the browser plugin gets uninstalled by the package update, visiting a web site that requires a Java plugin will cause the browser to automatically suggest installing OpenJDK/icedtea-plugin.

Multiple times in this discussion thread you have talked about the plugin, but the comment about forcibly removing (as opposed to just disabling) has to do with the JDK, not the plugin. Yes: interactive systems where a user is staring at a web browser designed to download and install plugins is a simple situation to handle. However, servers that are running mail processing backends or websites are entirely different animals.

We are only forcibly removing the plugin for now. Hopefully you will no longer be running your mail servers on an ancient JDK that contains multiple security issues once we do decide to remove it.

Believe me, I would have preferred to simply push out an update to the newest version.

For the record, I don't use this package at all (I do not currently use Java at all, in fact, although I have extensively in the past while tending sites running on Tomcat). However, all of my servers use Ubuntu, and the idea that removing the JDK is considered a security patch, which normally should "do no harm, add no features, change no behaviors, and only fix bugs", clearly underscores that the Ubuntu upgrade process is not safe.

I mean, honestly, and you can say "that's stupid, you shouldn't do that, now your argument has jumped the shark", but this policy, if understood by actual users, would simply cause people to never install security updates at all. You want security updates to be a no-brainer: there should never be a downside to installing a security update; you don't want people second-guessing a security update because it might just uninstall the package entirely.

On the other hand, you don't want thousands of people left with out-of-date versions of the sun JDK. Suppose that a critical vulnerability was found in the last version of the Sun JDK plugin that still had the DLJ? Would you then support removing it in a security update?

Leaving browser plugins that can't legally be upgraded laying around people's systems is a severe security flaw, so the decision to invasively remove it is definitely the best option.

How about leaving it installed, not allowing it to be reinstalled, and showing a notification that the software needs to be upgraded manually?

This only works if the person who sees the notification is actually in a position to make a conscious decision on the risk of leaving it installed, and possesses the technical knowledge required to manually install it.

...so we are saying that the person in charge of running security updates on production servers /is/ in a position to make a conscious decision on the (apparently now high) risk of installing what seems like a simple update, and possess the technical knowledge to figure out why suddenly nothing works anymore?...

I mean, this isn't even something they could easily undo: the old packages won't be able to be distributed anymore. They would either have to manually install the SDK themselves in a way compatible with the Ubuntu package distribution, or install OpenJDK and hope for the best (which, as you yourself point out, is unlikely to work, as there is likely a reason they installed the Sun JDK in the first place).

You can download all the previous versions here:

https://launchpad.net/ubuntu/+source/sun-java6/+publishinghi...

Easy to undo if an insecure version is acceptable to you, and once installed, use apt pinning so it doesn't get upgraded anymore.

For sake of argument, I just tried to download 6.24-1build0.10.10.1 of sun-java6 for Natty from that website, and the site simply told me it, and all files related to it, were "(deleted)". (Which is so silly and obvious, I have to ask: was this a real suggestion, or are you just trolling me to waste my time checking? ;P)

Honestly: I have never known Ubuntu to keep an old package around. There was a new update released today, 6.26-2natty1, and the now hours old version 6.26-1natty1 is already marked: "removal requested in 16 hours". Do you have a more serious suggestion for how the old packages could be obtained?

That means they were deleted from the repository, but they are still archived in launchpad. The reason you don't see the files for 6.24-1build0.10.10.1 is because they were copied over from maverick. If you want the 6.24-1build0.10.10.1 files, you can get them here (click on the architecture you want to download under "Builds" on the top right):

https://launchpad.net/ubuntu/maverick/+source/sun-java6/6.24...

No, I was not trolling you to waste your time.

All old packages are archived in launchpad, even after they get removed from the archive.

sigh. I go to that URL, and under builds I click "maverick amd64". I then have to select which binary package I want. Let's select "sun-java6-bin 6.24-1build0.10.10.1", as that one will be most critical to someone trying to deal with their JVM disappearing.

At this point, you are presented with the "(deleted)" notice next to the file. In fact, along this path you have been presented with "(deleted)" next to every useful download (such as for sources); the only thing you can get is a 318.5 MiB diff from 6.22-0ubuntu1~10.10.

So no: old packages are /not/ archived in launchpad, and I feel you are just helping prove that. Accordingly, I will now reassert my question re wasting time. Seriously: this is ridiculous; are you even trying these links before claiming they work in specific ways?

Oh, sorry about that, you're right. It appears that the partner archive in Launchpad _does_ actually remove packages after a certain time. My bad.

Considering the steps required to install the Sun JDK in the first place, is it really a stretch to believe these people are able to make a conscious decision about leaving it installed?