[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Git Packaging: Native source formats



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


Reply to: