Bug#849058: python-debian: Use ‘distro-info’ data for Debian versions

[Stuart Prescott]

Hi Ben,

>> Strong NAK for adding python-distro-info as a runtime-dependency in
>> Debian.
> 
> Hmm, my intention was “use the library if it's available, fall back to a
> bundled-and-possibly-outdated data file if not”. But your later NAK
> covers that, too.

If distro-info-data were already in the standard task, "maybe" (with the 
caveats already discussed). If we knew how this function was used and were 
happy that these variable semantics matched that use, "OK". Really, people 
probably should use distro-info-data for this in any case, but this function 
in python-debian pre-dates python-distro-info. Perhaps a deprecation warning 
around this function would start to shake out the users and move them 
elsewhere.

> I would argue that ‘distro-info-data’, or some other simple
> machine-parseable set of Debian release names, should be part of the
> standard task. It's very small, should be implemented in one place, and
> allows interrogating the system to automate questions about Debian
> generally. That seems suitable.

Maybe. I don't think this fits "things you'd expect to find on any un*x like 
installation" which is the historical definition of the standard task. I 
don't want to be the one adding more packages to the standard task. I think 
that should be the same procedure what we once had as elevating the 
privilege of a package -- a rough consensus on d-devel/d-policy.
 
>> Also a strong NAK for having possibly different results depending on
>> whether the code is run on Debian or in some other environment […] I
>> don't think python-debian 1.30's list_releases should ever change its
>> output.
> 
> Okay. I had imagined a different API, that makes ‘python-debian’ and
> ‘python-dist-info’ more closely aligned: they both refer to whatever is
> the current Debian operating system. Would you say the purposes are not
> compatible in that way?

As indicated, deprecating this function in favour of python-distro-info 
might make sense. There's no point in having two views of the same data if 
these functions are to do the same thing.

>> distro-info-data also misses bullseye which would currently be
>> included in the 1.30 release.
> 
> I don't understand this remark. What bullseye is being missed?

The "bullseye" release is not included in distro-info-data while it is 
included in the currently committed patch for this bug. (See #851447)

>> Separately to your other commits, c114ae4 (fixing ._name__) looks like
>> it is worth independently cherrypicking out of the collection. Well
>> spotted. It also indicates that the test suite coverage of that bit of
>> code needs improving (there is currently almost none of that class).
>> It would be good to have tests accompany fixes like that -- even a
>> smoke test would have caught that bug.
> 
> Yes, the test suite has many errors even before I got to it. 

No. As you've already seen in touching this code, the test suite is being 
run at build time on the buildds and also on the ci.d.n infrastructure.¹ The 
test suite obviously passes there or there would be RC bugs filed (and 
fixed). As already described, the test suite passed fine up until you broke 
it.

[1]	https://ci.debian.net/packages/p/python-debian/

> I'd like to
> (contribute to?) work on getting the test suite at least passing, before
> adding more test cases. That would IMO be a separate merge request though.

"Find a bug, write a test that exposes the bug, fix the bug to make the 
tests pass again" has long been the approach in python-debian. Whether the 
new test and the fix are in the same commit or consecutive commits doesn't 
worry me but they should go together. (Same commit implies tests always pass 
which is good for bisecting but couples exposing bug with the proposed 
fix... I don't care enough to have an opinion as long as bugs are actually 
fixed.)

cheers
Stuart


-- 
Stuart Prescott    http://www.nanonanonano.net/   stuart at nanonanonano.net
Debian Developer   http://www.debian.org/         stuart at debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7