Ticket #731 (new enhancement)

Opened 14 years ago

Last modified 13 years ago

update-manager should warn that third-party sources may not support the new distro

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


This is kind of the second half of #365.

With  LP:147080, third party repositories can be configured to not be disabled during upgrades (and in fact we do this in /etc/update-manager/release-upgrades.d/debatheba.cfg). However, by the same token, the third party repository may not yet support the new distro.

We should maybe convince upstream to check for "AllowThirdParty?=yes" in the "[Sources]" section of the release-upgrade config and display a message saying something like "Third party sources are currently enabled. Check with the maintainers of your third party repositories to ensure that $NEW_DISTRO is supported."

Change History

comment:1 Changed 14 years ago by geofft

On the slightly-questionable front, we can have debathena-upgrade-config set /etc/update-manager/meta-release to point to us for the "meta-release" file (cf. the  upstream one), and make ours not list new releases until we're ready. Or even just have ours list an upgrader of our own, that either errors out with "Debathena doesn't support shis release yet. If you continue Debathena will be uninstalled, or you can hang tight for a few days" or calls Ubuntu's. It looks like the upgrader is checked against the regular apt keyring (see gpgauthenticate() in DistUpgrade?.DistUpgradeFetcherCore?), so we can sign an upgrader with the Debathena key and have it be trusted.

I fear we may start to want including our own release-upgrader code at some point in the future. We got disturbingly lucky with the Maverick one, since Ubuntu's upgrader anyway forces overwriting files, which we needed to have happen. In theory Ubuntu is better than we are at packaging, and they have all sorts of custom code to clean up after themselves, and we might actually want in on that opportunity at some point.

comment:2 Changed 14 years ago by andersk

I hope you agree (it sounds like you do) that Debathena really, really don’t want to be in the business of being responsible for Ubuntu upgrades. If we truly have no other options, it would be way better to tell users that the supported upgrade path is uninstalling Debathena, upgrading Ubuntu, then installing Debathena again.

comment:3 follow-up: ↓ 4 Changed 14 years ago by geofft

That makes preserving configuration across the upgrade quite hard (notable examples of post-config-package-dev conffiles that people may care about include /etc/security/access.conf).

I don't really have compunctions about being the gatekeeper for Ubuntu upgrades and just including a usually-improper subset of Ubuntu's meta-release file (still pointing to actual upgraders from Ubuntu's servers). I am significantly more worried about writing our own upgrader to wrap Ubuntu's, but I feel like in the event that we face an awkward upgrade path, the advantage to user experience may justify leaving that option open to ourselves. (Until we have to use that option we can just point to Ubuntu's upgrader.) The only thing this will require is a webserver with decent reliability, but we're basically making that guarantee about both debathena.mit.edu and athena10.mit.edu at the moment.

I can see writing an upgrader to error out simply for UX reasons (as opposed to suppressing the claim that an upgrader exists at all) as sufficiently sketchy to not be worth it, but I don't greatly see the failure modes in either suppressing upgrade choices or, if faced with a difficult situation, carefully writing and testing a "Debathenified" upgrader.

comment:4 in reply to: ↑ 3 Changed 14 years ago by andersk

Replying to geofft:

That makes preserving configuration across the upgrade quite hard (notable examples of post-config-package-dev conffiles that people may care about include /etc/security/access.conf).

Although that sounds like a hard case, it should actually work fine, because /etc/security/access.conf.debathena is a conffile and changed conffiles get preserved across uninstallation and reinstallation. (This isn’t an accident; Debian packages are supposed to preserve local configuration until the user purges them.)

comment:5 Changed 13 years ago by jdreed

I did some testing with this today, and I think the right answer is to change the meta-release file to point to a URI we control. There are still a couple of screw cases:

  • what if -standard and -login work, but -workstation doesn't? Is the release "supported" or not?
  • should this be opt-in or opt-out?

Personally, I think, if you install Debathena, you really don't want to upgrade to something we don't support. And if you do want to upgrade to something that will break your system, you're smart enough to override this mechanism. However, I'd be ok with making it a question (that defaults to "yes") in the installer (and manual install people are presumably clueful enough to deal).

Whatever meta-release file we point people at could either be a static file (that we only fetch from Ubuntu once the release works), or a CGI script that checks a flag file we set (or, awesomely, debian-versions.sh). We should maybe also consider shipping our own ReleaseNotes? and ReleaseNotesHtml? listed in the meta-releasqe file.

An alternative, is simply to transform meta-release on the fly to point at our own upgrader tarball which, prior to running the standard upgrade, checks a Debathena URL, and if the target release isn't supported, loudly inform the user that this is a terrible idea (but let them continue if they insist). However, looking at the "oneiric.tar.gz" tarbomb that they ship, I'm scared, because there are things named "demoted.cfg.hardy" and "prerequists-sources.dapper.list", so I don't think I want to touch that code.

comment:6 Changed 13 years ago by jdreed

If we divert meta-release, I wonder if we want to divert /usr/lib/update-manager/release-upgrade-motd to maybe check some URL and say something like "New release 'oneiric' has been released by upstream, but is not yet supported by Debathena". Though maybe I'm over-thinking it

comment:7 Changed 13 years ago by jdreed

If we go this route, note that meta-release{,-lts} is cached in /var/lib/update-manager _AND_ in $HOME/.cache/update-manager-core/meta-release. For maximum awesomeness, the GTK update-manager checks the former, and do-release-upgrade checks the latter.

comment:8 Changed 13 years ago by andersk

Can we talk to upstream before we try to do something silly like this? They were very responsive when broder got them to implement the /etc/update-manager/release-upgrades.d mechanism in the first place. I bet it would be really easy to have them add a configuration option that just says “before upgrading, display this warning text and prompt the user”.

Note: See TracTickets for help on using tickets.