Sean Whitton <spwhitton@spwhitton.name> writes: > Hello, > > On Sun 21 Dec 2025 at 05:49pm +01, Simon Josefsson wrote: > >> Sean Whitton <spwhitton@spwhitton.name> writes: >> >>>> ... as tag2upload does not support including the upstream release tags >>>> and their signatures either. >>> >>> tag2upload does support including the usptream release tags -- indeed, >>> it relies upon doing so. We archive them all in our append-only git >>> depository. >> >> I don't see any upstream git tags on browse.dgit.d.o, where are upstream >> tags stored? How is the above achieved? > > Oops. You're right, while we convey the things *pointed to* by the > tags, we don't convey the tags themselves. We got stuck on namespacing > issues; ideas would be welcome: #1106073. Given how things are designed right now, I think it is a good idea to not pollute the dgit view with non-Debian tags. How to authenticate what is a "upstream tag" and what is not? What to do when upstream modify the tags? Or changes the content of the tag? If you rename tags, how to deal with tags that carry semantic information used during the build? Personally, I think the Proper Way out of this is to not bother storing upstream source code in any Debian git repositories. Just store the debian/* files, a hash of the orig source code components, and some URL to retrieve them. The URL may be to the Debian archive, and the hash could be a simple SHA3 of tarball or some content-based hash. Just like our DSC files. That is how RedHat, Guix, Brew, ArchLinux, and most other packaging systems I know of works. In fact, does ANY other packaging system make a copy of upstream source code into git? I can't recall any. Storing a non-pristine copy of upstream source code in git is a gigantic rathole and I'm not optimistic it can be resolved in any elegant way. The world isn't all 100% git and won't ever be. The above problem is just a consequence of this approach. Storing a hash and a URL is simple and moves the problem elsewhere, where other tooling can solve it. My perception is that dgit tries to tackle a hard problem here, which is admirable, and there is value in trying to do this when everyone else gives up. But I'm not sure all the complications arising from this design can be resolved satisfactorily, or that it even bring enough value to offset its costs. Ironically, I do miss having upstream git tag information in the dgit view, and would make use of the information if you manage to convey it. Few aspects in this area are 100% right or 100% wrong... /Simon
Attachment:
signature.asc
Description: PGP signature