Ticket #365 (new enhancement)

Opened 11 years ago

Last modified 9 years ago

do-release-upgrade should check installability of Debathena

Reported by: jdreed Owned by:
Priority: low Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

At release-team today, we talked about the possibility of diverting do-release-upgrade to fetch some file from debathena.mit.edu which indicates what releases (and architectures) Debathena works on. For example, we may not be ready for Karmic the day of its release. Therefore do-release-upgrade should say something like "Debathena has not yet been released for Karmic, and some things might not work. Upgrade at your own risk. Y/N?"

Change History

comment:1 Changed 11 years ago by andersk

Graphical upgrades launched from update-manager don’t go through do-release-upgrade.

comment:2 Changed 11 years ago by broder

I, uh, suppose that transforming /etc/update-manager/release-upgrades to set Prompt=never would be the wrong approach, right?

*ducks*

comment:3 Changed 11 years ago by andersk

You have got to be kidding.

comment:4 Changed 11 years ago by jdreed

The goal is not to prevent users from upgrading, but rather to point out when they're likely to be shooting themselves in the foot and give them an opportunity not to.

That having been said, "Prompt=never" is almost certainly the right answer for cluster machines...

comment:5 Changed 10 years ago by jdreed

  • Milestone changed from Summer 2010 (Lucid Deploy) to IAP 2011

If we are clever with our clusterinfo (see #303), we could possibly set Prompt=never for -workstation and higher, and write our own applet which checks both the availability of an Ubuntu upgrade and a Debathena one. Or something.

comment:6 Changed 10 years ago by jdreed

  • Milestone changed from Natty Alpha to Natty Release

So, /etc/update-manager/meta-release lets us configure the URI for the meta-release file. We could provide our own file which is purposely delayed until Debathena support is available. This may be too intrusive for -standard or -clients users, however. Alternatively, we could not lag the meta-release file, but swap out the ReleaseNotes? URI for our own page that tells users whether or not Debathena is supported (and then links to the real release notes). But that assumes people _read_ the release notes.

The Right(tm) way to do this is to get upstream to take some patch that checks if Allow3rdPartySources is enabled, and checks some URL to see if the 3rd party source supports the distro, and communicates that to the user. This is undoubtedly far more work than just ensuring Debathena is usable as close to release-date as possible.

comment:7 Changed 10 years ago by jdreed

  • Milestone changed from Natty Release to Fall 2011

comment:8 Changed 10 years ago by jdreed

  • Milestone changed from Fall 2011 to Oneiric Support

comment:9 Changed 9 years ago by jdreed

  • Milestone changed from Precise Beta to The Distant Future

We managed to not suck for Precise this year, for at least -standard and -login. I vaguely wonder if we should transform the meta-release file if you have auto-upgrade installed, and not care otherwise. Or simply not care.

Note: See TracTickets for help on using tickets.