Mattia Rizzolo writes: > On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote: >> The .buildinfo files are referred to in the .changes files; renaming >> them would require updating the .changes file. The .changes files are >> used to upload the security updates to ftp-master. > > With .changes being ephemeral, it feels to me that using them to cross > the archive is not really a good solution, and whatever is used to copy > packages from one archive to another (is it dak itself?) should instead > re-create the upload and re-sign it. Also because that way it would be > perfectly able to "upload" all of the sources+binaries from sec-master > to ftp-master in a single go, which can't be bad.
We also currently require .dsc to be signed by the same key as the .changes; that wouldn't work either. There are some advantages to changing the way the sync works, but it's not a priority to look at. There are enough other things... >> ftp-master also has the same problem when uploads end up in policy >> queues (the renaming to .buildinfo.N is only done when dak is "done" >> with the file and will never touch it again). > > Also here, it feels to me that once something is accepted into a policy > queue, dak should already consider it something controlled by itself, > store checksums in the database and be done, not keep the .changes > around as a "source of truth" for additional processing, imho. Throwing away .changes doesn't help with .buildinfo name conflicts. > Sure, I understand that things works like that, I'm just showing a few > design points that could potentially be done differently. We could also just not accept .buildinfo uploads when they don't contain useful information about published binaries, that is for source-only uploads. Maybe I should reenable the check for this at least on security-master? It was rejecting uploads that are okay for unstable/experimental so I disabled it again the last time. Ansgar