Bug#983065: debian-policy: Downgrades are not allowed / Package upgrades must have a greater version than previous packages of the same name in the same suite
Hello Axel, On Thu 18 Feb 2021 at 11:01PM +01, Axel Beckert wrote: > I know this is very obvious, but if you read > > * https://www.debian.org/Bugs/Developer#severities and > * https://release.debian.org/testing/rc_policy.txt > > it seems as if it should be listed somewhere in the policy that package > downgrades MUST not happen during upgrades within the same suite > (i.e. also not during dist-upgrades from e.g. oldstable to stable). > > I searched for "downgrad" (case-insensitively) in the whole policy and > read at least the sections 3.2 "The version of a package" and 5.6.12 > "Version". (If it's documented elsewhere in the policy, it might need a > pointer to there in these sections.) > > Reason for this bug report: > > After reading https://release.debian.org/testing/rc_policy.txt, > especially after word "complete" this paragraph … > > The purpose of this document is to be a correct, complete and > canonical list of issues that merit a "serious" bug under the clause > "a severe violation of Debian policy". > > … I really had a hard time arguing why https://bugs.debian.org/983018 is > actually release-critical, despite I was 100% sure that it is. Luckily > the maintainer did not start discussing but just fixed it. :-) > X-Debugs-Cc'ing the release team for the involvement of rc_policy.txt. Thanks, yes, let's document this in Policy. There would seem to be two things to write down: - .debs are not expected to support downgrades, either in their maintainer scripts or in any other aspects - something about using version numbers correctly so that apt doesn't want to downgrade / doesn't get blocked because a downgrade would seem to be required > The best written source I so far found was > https://wiki.debian.org/SystemDowngrade and hence outside the policy. > > I suggest to add maybe a section 3.2.3 at > https://www.debian.org/doc/debian-policy/ch-binary.html#the-version-of-a-package > with a text like this: > > ---8<--- > 3.2.3 Version numbers of upgrades within one suite > > Version numbers of succeeding package upgrades within the same suite > MUST be strictly greater than the one of the previous package. > > Package downgrades within one suite or when dist-upgrading from an old > stable to a new stable release MUST not happen. > > See 5.6.12.1. Epochs should be used sparingly for cases where you need > to package an upstream release with a lower upstream version > number. Even in that case the package version itself MUST be greater. > --->8--- I don't think this text is clear enough -- Policy is about the contents of packages, but it's phrased in terms of things which will happen -- it refers to upgrades and to downgrades. Could you try writing this in terms of what contents of packages must be avoided in order to avoid the situations you describe? Also, I think the thing about not supporting downgrades should be somewhere too. -- Sean Whitton signature.asc Description: PGP signature
Bug#983065: debian-policy: Downgrades are not allowed / Package upgrades must have a greater version than previous packages of the same name in the same suite
Package: debian-policy Version: 4.5.1.0 Severity: normal Hi, I know this is very obvious, but if you read * https://www.debian.org/Bugs/Developer#severities and * https://release.debian.org/testing/rc_policy.txt it seems as if it should be listed somewhere in the policy that package downgrades MUST not happen during upgrades within the same suite (i.e. also not during dist-upgrades from e.g. oldstable to stable). I searched for "downgrad" (case-insensitively) in the whole policy and read at least the sections 3.2 "The version of a package" and 5.6.12 "Version". (If it's documented elsewhere in the policy, it might need a pointer to there in these sections.) Reason for this bug report: After reading https://release.debian.org/testing/rc_policy.txt, especially after word "complete" this paragraph … The purpose of this document is to be a correct, complete and canonical list of issues that merit a "serious" bug under the clause "a severe violation of Debian policy". … I really had a hard time arguing why https://bugs.debian.org/983018 is actually release-critical, despite I was 100% sure that it is. Luckily the maintainer did not start discussing but just fixed it. :-) X-Debugs-Cc'ing the release team for the involvement of rc_policy.txt. The best written source I so far found was https://wiki.debian.org/SystemDowngrade and hence outside the policy. I suggest to add maybe a section 3.2.3 at https://www.debian.org/doc/debian-policy/ch-binary.html#the-version-of-a-package with a text like this: ---8<--- 3.2.3 Version numbers of upgrades within one suite Version numbers of succeeding package upgrades within the same suite MUST be strictly greater than the one of the previous package. Package downgrades within one suite or when dist-upgrading from an old stable to a new stable release MUST not happen. See 5.6.12.1. Epochs should be used sparingly for cases where you need to package an upstream release with a lower upstream version number. Even in that case the package version itself MUST be greater. --->8--- Maybe some of the phrases from https://wiki.debian.org/SystemDowngrade can be reused, too. Mostly thinking of these, because these are the core reasons: 1. The packages' installation scripts (postinst...) are designed to handle upgrade only. 2. The installation tools are designed to replace older versions of packages by newer versions. Improvements of this text are very welcome as it's currently just a first brain dump. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 3.4.3-1 Versions of packages debian-policy suggests: ii doc-base 0.11.1 -- no debconf information
