Package: git-depush
Version: 13.0
tag2upload(5) is unclear about metadata item repetitions and
ordering.
Matthias Urlichs writes ("Re: Pythonista wanted for help with tag2upload
testing [and 1 more messages]"):
> I've been thinking about that; the problem is that the data structure to use
> depends on the intent of the duplicated tag(s). I mean, I could envision
> something like
>
> [dgit distro=debian tag=1:42.1-1]
> [dgit distro=ubuntu tag=2:42.1-2]
>
> as one perfectly obvious and quite reasonable interpretation of what a couple
> of duplicate metadata tags could possibly mean, but which would require
> somewhat different handling than
>
> [dgit distro=debian distro=ubuntu tag=42.3-4]
>
> which may or may not be intended to be different from
>
> [dgit distro=debian]
> [dgit distro=ubuntu]
> [dgit tag=42.3-4]
>
> So I'd recommend usecases > spec > implementation, not the other way 'round. ;
These are very interesting scenarios to consider.
Several of them supposes the possibility of some kind of notion of
"related tags" - a relationship between tags that depends on placement
or ordering, or something. That possibility is left open in the
current spec wording.
I agree with Matthias's point that this makes very unclear what the
the data model is, that's the result of parsing the metadata items.
Currently the spec says:
The placement and ordering of metadata items is not relevant, unless
specified otherwise here.
I think we ought to rule out that the relevant placement of two
different items is ever relevant, and exclude this kind of
semantically-relevant interleaving.
Ie, to take Matthias's first example, we should probably not invent
such an extension. Instead we should do:
[dgit distro=debian tag=debian=1:42.1-1]
[dgit distro=ubuntu tag=ubuntu=2:42.1-2]
and define that it is semantically equivalent to (say)
[dgit distro=debian tag=debian@1:42.1-1 tag=ubuntu@2:42.1-2 distro=ubuntu]
I think we may want to preserve ordering within a keyword, since
that's straightforward. So this would be *different*
[dgit distro=debian tag=ubuntu@2:42.1-2 distro=ubuntu tag=debian@1:42.1-1]
We might choose to spell such an extension
[dgit distro=debian tag=debian=1:42.1-1 tag=ubuntu=2:42.1-2 distro=ubuntu]
with an `=` in the value, or
[dgit distro=debian tag.debian=1:42.1-1 tag.ubuntu=2:42.1-2 distro=ubuntu]
embedding the "scope" in the tag name.
How about this text for the spec:
The placement and ordering of metadata items is not relevant, except
for the relative ordering of items with the same keyword. A keyword
may be repeated iff this is stated in its description. Unknown
keywords are ignored (and may be repeated).
So the abstract data model of a whole parsed but not interpeted tag is:
map, from keyword, to nonempty sequence of optional values.
In Rust-ish syntax, `Map<String, Vec<Option<String>>`.
?
Ian.
--
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.
