On Wed, Jul 06, 2011 at 12:53 -0700, Russ Allbery wrote: > Wolodja Wentland <babilen@gmail.com> writes: > > > I've recently started to work on some packages and am not sure if I > > follow best practices when packaging software from git repositories with > > git-buildpackage. > I do the following for OpenAFS (see the supporting scripts in the openafs > source package) based on work done by Sam Hartman for krb5, and I'm very > happy with it. I'm probably going to eventually adopt the same approach > for all other software with a Git upstream. Thanks Russ for officially blowing my mind :) -- But seriously, that *feels* like a good approach. [ ... ] > 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? > Importing a New Upstream Release [ ... ] > 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? > 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? -- .''`. Wolodja Wentland <babilen@gmail.com> : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
Attachment:
signature.asc
Description: Digital signature