Joseph Beckenbach <[email protected]> writes: > “Dumb” question here: isn’t the subtleness coming from the baked-in > assumption that *only* tag2upload may use it and nothing else is allowed > to?
Yes, at some level that's always true: The fields could be defined a different way. If the participants in the discussion at the time had the use case discussed in this thread in front of them, maybe they would have picked a different design. > Ah, there’s what I missed on first read-through: these are spec'ed for > tool-use only. Yet the fields are not obviously named as off-limits for > non-tool-use. Hmm. It's not tools in general -- presumably any headers are going to be created by some tool -- but specifically a tool that generates the upload to the archive based on a signed tag. But yes. The *description* of the field in Policy makes this fairly explicit (I think), but I agree that the name of the field in isolation doesn't make that obvious. > How about making visible that tooling is involved and expected/desired, > not manual uploading? (Inventing a name here) “X-Upload-Helper: > tag2upload” in relevant control file, then tag2upload refuses to upload > anything with X-Upload-Helper missing, empty, or not 'tag2upload’. That's not how the field works, though. It's not added by the user; it's added by tag2upload. The trigger for tag2upload to decide to act on the package is separate and doesn't involve control fields. > And Git-Tag-* fields can be re-spec’ed as usable manually and compatibly > to how tools interpret it. Sure, it's possible to do that, but it's a backwards-compatibility break at this point. That doesn't mean we can't do that, but it means we probably should look at other solutions that don't require breaking backwards compatibility first. > Apologies for revisiting if I missed earlier discussion where this was > brought up and beaten out in the solution space. Well, yes, that's what's happening in this whole thread, but that's fine! There are a lot of things going on in Debian at any given moment and people can't pay attention to all of them. That's not something you have to apologize for. The drawback of belated design feedback is that it's harder to incorporate, though. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
