Bug#875306: python-debian: include a type for buildinfo files

[Stuart Prescott]

Hi Chris

Thanks for having a look and offering some feedback!

On Tuesday, 27 October 2020 00:04:03 AEDT Chris Lamb wrote:
> Thanks for working on this. I can't think of any additional data that
> would be useful right this second. However, I tend to have to use the
> library in the 'real world' before I can discover that kind of thing.

I completely understand and I'm happy to expand the API once real use tests it 
out a bit. I might mark it as "experimental" in the documentation just in case 
real use suggests that some breaking changes are needed too.

> > The current code doesn't handle dequoting the environment values and will
> > react particularly badly to environment values with newlines in them.
> 
> Do you plan to address this? Would be nice if callsites would be able
> to rely on the quoting, as you might imagine.

Yes, I think it should do so. I will need to recompletely rewrite that bit of 
code to accommodate some of the weirder possibilities that are permitted, also 
checking the code in dpkg that generates the file.

> Glancing at the parsed data structures, it would seem like the code is
> collapsing duplicate environment keys in the returned value of
> get_environment() as well as throw away the original ordering. I would
> be okay with this, but we don't do the same for the
> installed-build-depends relation. Is this deliberate?

It is deliberate, although inconsistent as you note. I'm happy to be told me 
reasoning is not sound and that different structures would be better:

* I chose a dict for the environment as order doesn't matter for the 
environment and there can't be duplicates in the environment anyway. Python's 
precedent of using a dict for os.environ felt compelling. We could use an 
OrderedDict here to explicitly preserve order if that desirable (the dict will 
accidentally preserve order of course).

* I chose a list for the dependencies as that is what is already used for all 
other package relations within deb822._PkgRelationMixin/deb822.PkgRelation. 
Ordering of a Depends or Build-Depends may or may not actually matter there as 
that's down in the weeds of the implementation details of how apt would 
resolve alternate dependencies. In the case of Installed-Build-Depends, the 
package list is all-encompassing and should be installable without additional 
resolution (although I expect that might be simpler to say than do); order 
shouldn't be an issue there, but I prioritised code reuse and consistent data 
structures within Deb822 so that existing consumers of the structures from 
_PkgRelationMixin are usable.

The code also only currently consumes these data structures with no provision 
to edit them via the parsed versions (although the Deb822 super-class would 
let you edit the raw text and reserialise that to make changes). I've written 
it on the assumption that dpkg would always be the generator of the file and 
that python-debian is only providing tools to support analysis.

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