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

Re: Git and tarballs



Wolodja Wentland <babilen@gmail.com> writes:
> On Wed, Jul 06, 2011 at 12:53 -0700, Russ Allbery wrote:

> [ ... ]
>> but for some other packages I want to use some of the files that are
>> generated as part of the upstream tarball release but aren't checked in.

> Ok, this is not necessary for me right now. Do you know how often the
> tarball does *not* correspond to a "git archive TAG" and therefore needs
> to be stored explicitly?

This will be the case for anyone who is doing traditional tarball-based
releases that contain generated files.  The Autoconf/Automake stuff is the
most common, but other possibilities include generated protocol
documentation, man pages generated via pod2man, or anything else where
upstream pre-generates some things.

A good argument can be made that the Debian package build should
regenerate all of that from scratch, but even when I'm doing that, I like
to have the *real* upstream tarball release be the basis of the Debian
packaging, so including that in Git makes pristine-tar and so forth much
more efficient.  This is particularly true when upstream signs their
tarball releases.

>>     3. Run debian/rules get-orig-source.  This will generate a tarball
>>        from the upstream Git tag using git archive, remove the WINNT
>>        directory, and create a file named openafs_<version>.orig.tar.gz in
>>        the current directory.

> How stable is get-orig-source across releases? What would I do if
> upstream suddenly decides to change the internal structure of the
> tarball? Why isn't the actual tarball tampering implemented as a
> standalone script and called from get-orig-sources, which would allow
> you to also apply it to manually downloaded tarballs?

For OpenAFS, I do it this way because I don't actually use the released
tarball, so the get-orig-source target generates a tarball.  For a package
where I was using a released tarball for the reasons described above, I
would dispense with this target entirely and just use uscan to download
the tarball (or acquire it some other way).

Here's the OpenAFS get-orig-source, for the record.  As you can see, it
doesn't change much.

# These variables are used by get-orig-source, to construct dkms.conf, and
# to set the build version.  You will need to change TAG to package stable
# releases instead of experimental releases.
DEBIAN  := $(shell dpkg-parsechangelog | grep ^Version: | cut -d' ' -f2)
DEBVERS := $(shell echo '$(DEBIAN)' | cut -d- -f1)
VERSION := $(shell echo '$(DEBVERS)' | sed -e 's/[+-].*//' -e 's/~//g')
TAG     := $(shell echo 'openafs-stable-$(VERSION)' | sed 's/\./_/g')
REPO    := git://git.openafs.org/openafs.git

# Upstream does tarball releases for major releases, but not for point
# relesaes, and the tarball releases are split into src and doc and
# contain the WINNT directory.  Dropping WINNT, which is not used on
# Debian, saves a substantial amount of space in the source package, and
# there's no reason to include the files generated by regen.sh when we're
# going to run it again ourselves anyway.
#
# This rule therefore generates an upstream tarball from the upstream Git
# tag, rather than the tarball release, without the generated files that
# are not in Git and without the WINNT directory.  It assumes that
# git-core is installed and there's network connectivity to the upstream
# repository.
get-orig-source:
	git archive --remote='$(REPO)' --prefix='openafs_$(DEBVERS).orig/' \
	    --format=tar '$(TAG)' | tar xf -
	rm -r openafs_$(DEBVERS).orig/src/WINNT
	tar cf openafs_$(DEBVERS).orig.tar openafs_$(DEBVERS).orig
	rm -r openafs_$(DEBVERS).orig
	gzip -9 openafs_$(DEBVERS).orig.tar

>>     7. Commit the tarball to the repository with pristine-tar, using the
>>        new local tag as the reference:
>> 
>>            pristine-tar commit <tarball> <local-tag>

> Why exactly is this needed when the tarball can be cut from upstream tags?

Each time you regenerate the upstream tarball from the Git repository, it
will change.  You have to store pristine-tar data for one specific
generated tarball, or someone who has only the repository won't be able to
recreate the tarball used in Debian packaging.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: