[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: