Re: [RFC] General Resolution to deploy tag2upload
Hi,
On 6/19/24 00:57, Aigars Mahinovs wrote:
This is *exactly* the same situation as we already have with
source-only uploads. There is a
state of the software upload that the developer signs off on and then
there are further technical
build artifacts that the developer does *not* sign - they are signed
by the technical systems that
generated those artifacts. And those systems are centrally maintained
for scalability, convenience
and security.
I agree with that, but it effectively changes what we consider a "source
package", and that comes with all the baggage of archival:
- we need to store the actual contents in the archive, not just a
reference to an online service, or the online service becomes part of
the archive.
- we need to distribute that on CDs and mirrors (which both have size
constraints)
- we need to keep and archive also the tools required for processing
- we still need to be able to comply with removal requests
- we need to be able to deal with "epochs" in package development
For example, the "clinfo" packages that were shipped in jessie and in
stretch and following are completely unrelated, they just have similar
enough output that one could be used as a replacement for the other.
If those had been git-maintained packages, how would those have been
archived? Is the dgit package namespace separate from Debian source
package names?
Building the conversion service is the easy part of the problem.
Simon
Reply to: