[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