On Wed, Jun 14, 2006 at 10:27:54AM -0400, Justin Pryzby wrote: > Package upgrades skipping a stable release are advertised as "not > guaranteed to work", which allows maintainers to drop support for > upgrades from versions earlier than oldstable in their uploads to > unstable. However I've never heard a requirement that package > versions earlier than the most recent stable release be purged before > installing.
> Recall that a package can be in "Config-files" state whenever it has a > postrm script, or it owns conffiles; also, if postrm fails, it is > considered to be still in "Config-files", even though its conffiles > will have been removed from the filesystem and package list. > Example: > U: Install foo-1, which either owns a conffile or has a postrm script > U: Remove (but don't purge) foo > M: Maintainer uploads foo-2 > D: Debian releases $stable, which includes foo-2 > U: Dist-upgrade to $stable > M: Maintainer uploads foo-3, which drops support for foo-1 > U: Dist-upgrade to $testing > U: Install foo-3 from testing, from state "Config-files" of foo-1, but > foo-3 only handles upgrade from foo-2; something terrible happens. > Does this mean that maintainers should be expected to support the > maintscript "install" "$2" cases for ancient versions, or is there > some other convention of which I remain unaware? It would be nice to support such upgrade cases as much as possible, but there's nothing even remotely approaching comprehensive testing of that upgrade path before release, so it's not release-critical and so users don't get much in the way of guarantees that this will work. Just like there's no guarantee that saying "no" to a conffile prompt when upgrading across stable releases will give you a usable package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
