Hi Ansgar, thanks for taking a look.
On Fri, 01 Jan 2021, Ansgar wrote: > Upstream can probably do a new release when the release managers > change. Either way, changing how to store upstream signatures doesn't > seem something that dak can change; thus closing the bug. But changing this will require changes to dak too, no? So if we decide it's the right approach, we should likely make this bug blocked on some other meta-bug. > > If we assume that the archive is meant to store immutable content > > under a given filename (and to me that requirement seems to be a good > > idea), then we should question ourselves whether we really want to > store > > those signatures in that way. They should either be tied to the > Debian > > revision (so that they can change over time without any new upstream > > release) or be incorporated in the Debian tarball. > > The archive currently doesn't enforce this: only that the currently > existing file doesn't change. People like to reupload identically- > named files with different contents, for example after an upload to NEW > was rejected and a subsequent upload happens. Changing the content after a NEW reject is legitimate. Changing once the file has been made public is supposed to not happen. dak actively tries to avoid this AFAIK but fails in multiple sub-cases. > We could change that, but that seems to be a different question than > handline upstream signatures. Is there a canonical bug for this request already? I would very much like to see dak fixed so that we don't have the possibility to re-export any previously-existing file with a different content. It's a pain for any derivative that might have kept the old file in some (old) suite because we don't have the same schedule. FWIW, this is something that I would seriously consider to sponsor through https://salsa.debian.org/freexian-team/project-funding Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
