Hi.
Back in the day, one of the big reasons for separating .orig.tar.gz from .diff.gz was to reuse upstream tarballs for space reasons, both in terms of space on mirrors when the pool had two Debian revisions with the same upstream, as well as to reduce upload time. Internet is faster and disks are cheaper. I assert this is much less of a concern than it used to be. It may be there is some small fraction of packages where this is still an issue. I have a question into mirror admins and ftpmaster that they had not gotten back to in a couple of weeks. Using native source formats (1.0 and 3.0 (native)) is attractive for some git workflows. It means you can just export the git repository and don't need to make sure that you use the same upstream tarball when upstream versions are the same. You don't need to synthesize a separate upstream tarball. It seems particularly attractive when upstream doesn't produce tarballs and instead does their development in git. I'd like to understand the downsides to doing this: * One is that you're not using upstream tarballs. If upstream has tarballs they produce, we're not using them. I guess we may end up having that part of the conversation now rather than later. It's clear that we value integrity of upstream source. That is we want to make it easy for people to start from some upstream source that is trusted because upstream has produced it and audit just our changes. One way to do this is with an upstream tarball and a diff (or set of diffs or a debian directory). But if we're thinking that people will be working in Git, another way to do this is to merge in a signed upstream git tag. Then you can perform a diff against that git tag. * I've heard at least one person claim that native format packages are problematic for downstreams. I'd like to better understand both the theoretical argument here and to understand from downstreams whether it is an issue in practice. For downstreams where it is a problem, are you using a git or a non-git workflow? Thanks for comments, --Sam
