Hello, On Tue 16 Jul 2019 at 10:45AM +02, Ansgar Burchardt wrote: > A "source package" generally consists of: > - a set of upstream artifacts (currently one or more tarballs, > signatures); can be the empty set for native packages > - Debian-specific artifacts > - the .dsc artifact (generated from the Debian part); consists of: > - strong cryptographic hashes of all other artifacts > (Checksum-*, Files, ...) > - convenience information extracted from Debian-specific artifacts > (Build-Depends, ...) > > Currently we represent all of these as real files that need to be > provided by the uploader. > > If you no longer want "source packages" as we have currently, you just > define another representation as the canonical one. > > So I would like to just change how developers can provide artifacts to > the archive: upstream artifacts can be specified as either a set of > URLs to retrieve them from or a Git tree; Debian-specific artifacts can > be a Git tree or (for source format 1.0) a diff between two Git trees. > > All artifacts provided must be covered by a strong cryptographic hash > which is signed by a developer. The hash must not only cover the Git > tree object itself, but also all content covered by it. > > We currently have "tar" as the serialization format covered by the > strong cryptographic hash and, as I value having a representation of > upstream artifacts in the published archive, believe we should continue > to provide the "tar" files. However this is not necessary; we could > instead provide only the Git tree. > > Currently this proposal should also allow multi-package repositories, > packaging-only repositories, packages using multiple upstream > artifacts, and ensuring Debian uses the same artifact as upstream. It > does not require any integrity from the VCS system. > > I think the .dsc artifact should eventually be split into the two > parts: the list of artifacts (together with strong cryptographic hashes > and where to locate them) signed by the uploader, and the convenience > information extracted from these. The second part should be generated > by the archive software. This is interesting. Thank you for explaining. For the vast majority of packages, the git-debpush/tag2upload system enables us to do away with a lot of the complexity that you describe here. It brings the Debian way of representing, using and transmitting source artifacts much closer to how upstream projects do things. I think it is good for Debian development, downstreams and users to be able to do away with that complexity when it is possible to do so. We can't apply git-debpush/tag2upload to all packages -- for example, packages with large binary datafiles which we wouldn't want to check into git. Or, as you mention, packages in monorepos. Perhaps maintaining those packages could be made easier by implementing something like your proposal. In the meantime, let's deploy the tag2upload service, which has already been coded up, and enable git pushes to upload for the vast majority of packages. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature