Bug#881431: debian-policy: Clarify a version number is unique field
Hello, On Sat, Nov 11 2017, Mattia Rizzolo wrote: > There is another reuse that you haven't considered here: reusing a > version (or even, a lower version) after a package has been removed > from the archive (and here I mean, remove from all of oldoldstable, > oldstable, stable, testing, unstable, experimental releases). At that > point dak doesn't know of it anymore and allows everything. > > TTBOMK that happened in the past several times. > > Do you want to forbid such "reuse" as well? I think so. There was a thread on -devel recently about the dangers of reuse in such cases: users with the old package installed are not able to switch to the new package. -- Sean Whitton signature.asc Description: PGP signature
Bug#881431: debian-policy: Clarify a version number is unique field
On Sat, Nov 11, 2017 at 07:07:48PM +0100, Christoph Biedl wrote: > Version number re-usage happens, probably always by accident. In the > past, before the advent of slugs to mark security uploads and the like, > this was more likely to happen, and a long time ago my src:file package > was affected by that as well[1]. Unfortunately, there was such an event > even in 2017, see #876633. There is another reuse that you haven't considered here: reusing a version (or even, a lower version) after a package has been removed from the archive (and here I mean, remove from all of oldoldstable, oldstable, stable, testing, unstable, experimental releases). At that point dak doesn't know of it anymore and allows everything. TTBOMK that happened in the past several times. Do you want to forbid such "reuse" as well? > So I'd like to suggest an addition to "3.2. The version of a package", > for clarification, wording in the simplest form: > > | For any package, a version number must never be re-used. > > What I'd like to express but I guess is a bit too long: > > | Unless bitwise identical, no two files that share the base name and > | have a version number in it may exist anywhere in the archives, ever. That's all good and nice, but it requires some techinical block on the archive software for it not to happen. > Also I feel a temptation to implement an according check in the > auto-reject machinery at ftp-master. But that's for another day. Personally I believe that should come *before* having it in policy. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#881431: debian-policy: Clarify a version number is unique field
Hello Christoph, On Sat, Nov 11 2017, Christoph Biedl wrote: > So I'd like to suggest an addition to "3.2. The version of a package", > for clarification, wording in the simplest form: > > | For any package, a version number must never be re-used. > > What I'd like to express but I guess is a bit too long: > > | Unless bitwise identical, no two files that share the base name and > | have a version number in it may exist anywhere in the archives, > | ever. Slight wrinkle here: epochs are not included in filenames. So we might have both foo_1.1.dsc and foo_1.1.dsc where one has version 1:1.1 and the other has version 2:1.1. > PS: Aside, I like the new presentation format of the policy document > as seen in . Improved > visual, policy version number at the very beginning, maintainer script > flowcharts, upgrading checklist included, but no additional and > dangerous requirements for using the document (i.e. works fine without > JavaScript). Much appreciated. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Bug#881431: debian-policy: Clarify a version number is unique field
Package: debian-policy Version: 4.1.1.1 Severity: wishlist Hello, this is in the category of "It should be obvious to anybody but I'd prefer things are well-defined in case anybody wishes to start an argument over that". So rather nitpicking. Version number re-usage happens, probably always by accident. In the past, before the advent of slugs to mark security uploads and the like, this was more likely to happen, and a long time ago my src:file package was affected by that as well[1]. Unfortunately, there was such an event even in 2017, see #876633. Such re-usage is fairly annoying: * It breaks a reasonable assumption about the features provided by a package installed in a given version. * It breaks caching proxies that rely on the uniqueness for performance i.e. no re-validation with upstream required. Also, proxies might retain packages for longer than they exist on a mirror. So I'd like to suggest an addition to "3.2. The version of a package", for clarification, wording in the simplest form: | For any package, a version number must never be re-used. What I'd like to express but I guess is a bit too long: | Unless bitwise identical, no two files that share the base name and | have a version number in it may exist anywhere in the archives, ever. Also, this is rather file-system based. But it should serve the first purpose as well: If a package in a given version is installed on two systems, the same feature set is provided on both without a doubt. A few explanations: * As it says, it's about *all* files that have a version number in the name, source and binary packages, upstream tarballs, *.dsc, *.diff.*, *.debian.tar.* and anything else. * Files without a version number in the name like package indexes and documentation are considered volatile anyway. * Moving files around without modification is acceptable and also daily routine: Between the queues, also from security to -proposed-updates * By archive I think about the Debian files served by ftp.debian.org, security.debian.org, ftp.ports.debian.org and probably a few, rather semi-official more. Perhaps "archive" isn't the best word for this. As always about policy, I'm interested about the idea but don't stick to a particular wording. Feel free to improve as I'm also not a native speaker. Also I feel a temptation to implement an according check in the auto-reject machinery at ftp-master. But that's for another day. Regards, Christoph [1] Examples: * Completely different http://snapshot.debian.org/package/file/4.17-5etch2/ * Duplicate on .dsc only (different signature, how did *that* ever happen?): http://snapshot.debian.org/package/file/5.04-5%2Bsqueeze2/ PS: Aside, I like the new presentation format of the policy document as seen in . Improved visual, policy version number at the very beginning, maintainer script flowcharts, upgrading checklist included, but no additional and dangerous requirements for using the document (i.e. works fine without JavaScript). Much appreciated. signature.asc Description: Digital signature
