Bug#875306: python-debian: include a type for buildinfo files
stuart at debian.org
Wed Oct 28 08:05:42 GMT 2020
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.
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
More information about the Reproducible-builds