Ticket #365 (new enhancement)
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:2 Changed 15 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:4 Changed 15 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 14 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 14 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:9 Changed 12 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.
Graphical upgrades launched from update-manager don’t go through do-release-upgrade.