[Piuparts-devel] for 0.81: preparing for some larger changes

Andreas Beckmann anbe at debian.org
Mon Sep 11 23:51:23 UTC 2017


77936220e network issue: E: The repository '.*' no longer has a Release
file.
abf86c2a3 p-r: catch URLError
29d47e6e9 dwke: move some methods to piupartslib/dwke.py
f3cbc5920 *.py: consistently name and use file I/O helpers
f17fe88a3 *.py: consistently use 'with open(...) as ...:' for scoped
open files
77ecca997 p-r: check for master directory separately
8036a9dbf dwke: prepare for inserting some locking scopes
5cf466d84 p-r: make verbose messages more consistent


And here I have a naming problem, again, ... :-)

consider we have a package foo in stable2backports2testing
with the following versions available:
stable: 1 (or 2~debXu1)
backports: 2~bpo1 (and 2~bpo2 soon)
testing: 3

We get the candidate packages from backports, but override the
version (2~bpo1) with the one from the final distro (3), which
breaks "outdated" detection (e.g. 2~debXu1 > 2~bpo1).

Ideally we should identify the test with the full sequence of
version numbers (1,2~bpo1,3) instead of only the target version (3).
This would automatically trigger a test on backports (or stable)
updates, not only on testing updates (e.g. (1,2~bpo2,3)).

For single distro tests (e.g. sid), nothing changes (it's a
1-element sequence of versions).

How should we name this (1-to-n-element) sequence of versions (and, for
the time being, the 1-element approximation using only the final distro?)


Andreas



More information about the Piuparts-devel mailing list