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

[Ben Finney]

Stuart Prescott <stuart at debian.org> writes:

> I've never liked python-debian embedding such information. However, …

(Thanks for reviewing these proposed changes.)

> 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 the module python-debian is installed as part of the 'standard
> task' and so additional dependencies are not really welcome. (The
> standard task needs to be getting smaller not bigger!)

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.

> 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?

> (The [‘debian.debian_support.intern_release’] function is
> undocumented, we don't know what semantics it is supposed to have, we
> don't know how/if this function is used. We must be very careful with
> it. A starting point could be some documentation for it!)

I was thinking to more clearly define the valid set as as “whatever
historical set of codenames is true of current Debian”.

> 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?

> 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. 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.

-- 
 \       “Faith is the determination to remain ignorant in the face of |
  `\                 all evidence that you are ignorant.” —Shaun Mason |
_o__)                                                                  |
Ben Finney