On 2025-12-24 16:48:28, Russ Allbery wrote: > Iustin Pop <[email protected]> writes: > > If I would do a manual upload, and add these two fields correctly, that > > is, Git-Tag-Tagger: my name/email and Git-Tag-Info: pointing to a > > signed (by me) tag, I don't see how this wuold conflict with with the > > meaning of the fields when filled by tag2upload. The signature on the > > changes file would be mine, but that would be the only difference. > > The semantics are subtlely different. > > […] > > In other words, this field doesn't *only* carry the semantics that this > package corresponds to a specific Git tag. It *also* carries the semantics > that the package was prepared via an automated process based on that > signed tag. It also implies a few other possibly-relevant things that your > manual upload may not match, such as that the relevant annotated tag > object can be obtained from the dgit-repos server.
I see. This, even from reaading the update policy, is a bit surprising. > If we want a field that only means the former and not necessarily the > latter, at least at first glance I think that should be a separate field > so that the semantics are clear. Fields are relatively cheap; we can add > more if we need to! I haven't followed the discussions (and while I tried to read "Debian’s git transition", I couldn't undersanding it), but having a field pointing to the exact signed tag used for uploads would be useful. With git-buildpackage, there might be an implicit rule for deducing the tag (which is what QA shows, likely), but having an explicit tag would be much clear. Possibly this is discussed in the mentioned "Debian’s git transition", but I missed it. (I'm still trying to understand what the future of packaging is, and what do I need to switch to, from my use of gbp) iustin
