Re: Removing transition stuff in debhelper scripts after which time?
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Removing transition stuff in debhelper scripts after which time?
Hi, Today I stumbled over the question: After which time should transition stuff be removed from the debhelper scripts. In this special case I'm talking about install-sgmlcatalog calls in (e.g.) postinst scripts. Adam Di Carlo announced the depreciation of install-sgmlcatalogs in 2001. However, almost all related docbook* packages still contain this stuff. So I'm wondering, how long one should wait before such obsolete stuff can be removed? I mean, there is no requirement to support updates from e.g. Woody to Lenny, right? I checked the Debian Social Contract and the Policy manuals, but didn't find an information related to this topic. Maybe I overlooked it? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing transition stuff in debhelper scripts after which time?
On Tue, Sep 25, 2007 at 04:46:43AM +0200, Daniel Leidert wrote: Today I stumbled over the question: After which time should transition stuff be removed from the debhelper scripts. In this special case I'm talking about install-sgmlcatalog calls in (e.g.) postinst scripts. Adam Di Carlo announced the depreciation of install-sgmlcatalogs in 2001. However, almost all related docbook* packages still contain this stuff. So I'm wondering, how long one should wait before such obsolete stuff can be removed? I mean, there is no requirement to support updates from e.g. Woody to Lenny, right? I checked the Debian Social Contract and the Policy manuals, but didn't find an information related to this topic. Maybe I overlooked it? I'm not sure where it's defined, but we don't support upgrades to anything other than the next release. So, unless it's needed to upgrade from an Etch system, it doesn't need to be in new releases of the package uploaded to unstable as of now. Now, that being said, it's often helpful (for backporting, for instance) to keep a bit more history in the scripts, but supporting woody is going a little overboard -- upgrading from Sarge would be absolute limit for me. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing transition stuff in debhelper scripts after which time?
On Tue, Sep 25, 2007 at 04:46:43AM +0200, Daniel Leidert wrote: Hi, Today I stumbled over the question: After which time should transition stuff be removed from the debhelper scripts. In this special case I'm talking about install-sgmlcatalog calls in (e.g.) postinst scripts. Adam Di Carlo announced the depreciation of install-sgmlcatalogs in 2001. However, almost all related docbook* packages still contain this stuff. So I'm wondering, how long one should wait before such obsolete stuff can be removed? I mean, there is no requirement to support updates from e.g. Woody to Lenny, right? I checked the Debian Social Contract and the Policy manuals, but didn't find an information related to this topic. Maybe I overlooked it? 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: . 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; . 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. . The package itself; eg. it might contain logic to upgrade the format of its datafiles but not for every historic version and bugs therein. Justin References [0] http://lists.debian.org/debian-mentors/2007/01/msg00241.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
