I'm sorry to say that I have two qualms about this. (Writing to #1111115 re git-buildpackage and #1111114 re uscan.)
Firstly, the spec for DEP-12 doesn't actually contain these fields yet and discussions are ongoing. But, more fundamentally: YAML is a very bad format. It is extremely complicated, has bizarre footguns eg the Norway problem [1] and implementations have a poor security record. We don't want every packaging tool that manipulates upstream git information to have to run a YAML parser. IMO it is a shame that DEP-12 used YAML rather than deb822. [2] I am very much in favour of having the upstream tag format information in a central place rather than a tool-specific file. But I don't think DEP-12 is the right place. (And we should drive this by implementing first in places like uscan and gbp and doing the design discussions afterwards.) I think probably what we should have is a new DEP for a single additional single-stanza deb822 file that exists only in the source tree and is ignored by dpkg-source, with a list of fields in that DEP. It wouldn't be restricted to upstream metadata. It could contain structured information about maintainer packaging workflows, for example. (Some fields might promote from this source-tree-only file, if and when we discover that they need wider use.) Thanks for your attention. Ian. [1] https://www.bram.us/2022/01/11/yaml-the-norway-problem/ [2] Other human-friendly data languages are available. I'm quite a fan of TOML, personally. But in Debian we usually use deb822. deb822, for all its quirks, is easy to parse, and we have much good tooling for it. -- Ian Jackson <[email protected]> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
