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.

Hello Axel,

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

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.