Hi, Justin Pryzby wrote:
You can drop such things in uploads to unstable after they're included in a stable release. Upgrades across releases are not tested and are officially "not supported" though AFAIK the reasons are largely undocumented. I think it's roughly the same situation as for downgrades:
It would nevertheless be a nice thing if people would not deliberately break upgrades just because there is no requirement for upgrades anymore.
To be honest, I was pretty annoyed when I had to switch my unstable system to "stable" when sarge came out in order to get the kernel version that was regarded as the new "minimum" to install further versions, and there was not even a safeguard in place that made sure that unstable->unstable upgrades crossing the kernel version in stable at this time were correctly rejected.
. maintainer scripts may not support things; this is basically so maintainers are allowed to drop support for ancient things and not have unmanagably large and difficult to test, unmaintanble cruft;
However you can create "sections" in the maintainer scripts, with the first section being active only if the last configured version (which you are told) is lower than the stable version, doing an upgrade to whatever the stable version expected, and the next section going from there to the current state. Since both of these are supposed to be idempotent on their own, this is no more difficult to maintain than a version that only supports upgrades from the latest stable.
. Package control file; including in particular the dependency fields: Conflicts, Depends, Provides (?), Pre-Depend plus Replaces. Dependencies on versions earlier than [old]stable are often dropped. It's only unfortunate that control files afaik still don't support comments to document why the versions and things were there with which to being.
I'd only drop things that are relevant only to stuff older than oldstable; I believe we could make an automated check for that (i.e. leave everything as it is, unless the versioned dependency will always be met even in oldstable).
The dependency fields help a lot in telling the package manager that it should not try something that is unsupported. Debian's renowned stability across upgrades doesn't come from nowhere.
. The package itself; eg. it might contain logic to upgrade the format of its datafiles but not for every historic version and bugs therein.
It might make sense to have a "Pre-Conflicts" (for lack of a better word) field that could be used to say "this package does not support upgrades from versions earlier than x". I'm not entirely confident current conflict resolvers could handle such a situation gracefully though.
Simon