Marco d'Itri <m...@linux.it> writes: > r...@debian.org wrote: >> My understanding is that the problem with this design from their >> perspective is that it requires a fat client on the uploader's system, >> and whole point of tag2upload is to stop requiring a fat client on the >> uploader's system. In particular, it requires all the code to >> reconstruct the source package from a Git tree be installed locally, >> which is basically a full dgit implementation.
> Does it? What if both the tag2upload client and server implemented > instead some very simple serialization and canonicalization algorithm > over the source package? The serialization isn't the problem, constructing the source package is. Once you have a source package, there are lots of things you can do, but the problem is precisely that going from a Git tree to a source package is non-trivial and involves a whole bunch of Debian-specific code. If you force one specific Git representation of source packages, the problem is much simpler (particularly if you choose a Git representation that is very easy to assemble), but one of the design goals of the whole dgit ecosystem, including tag2upload, is to try to meet people where they are and support as many of the Git workflows in use in Debian as possible. > I am thinking about hashing something like a sorted list of (file name, > file hash) tuples. I was trying to figure out while I was walking today whether that would be all you need, and I'm not sure it is. I couldn't convince myself that you could ignore file permissions, symlinks, hard links, and so forth. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
