Hi all,
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.
My main point of confusion is that I don't really see the need for tarballs
and what I am doing right now feels a bit clumsy and wrong. As my gut feeling
is typically a good indicator I feel the need for additional feedback.
Lets assume that I want to create a new package for software that lives on
github and releases have been tagged and are therefore available through
the githubredir service. Not everybody provides downloads, but you can
essentially download every commit as a tarball.
What I have been doing so far is the following (package foo):
--- snip ---
$ mkdir foo
$ cd foo ; git init
$ git remote add UPSTREAM_GH_USER git://github.com/UPSTREAM_GH_USER/foo.git
$ git fetch UPSTREAM_GH_USER
$ git checkout -b upstream UPSTREAM_GH_USER/master
$ git checkout -b master TAG_TO_PACKAGE
$ mkdir debian
$ dch --create
$ cat <<EOF > debian/watch
version=3
http://githubredir.debian.net/github/UPSTREAM_GH_USER/foo /([\d\.]+)\.tar\.gz
EOF
$ uscan --force-download --rename
$ pristine-tar commit ../foo_TAG_TO_PACKAGE.orig.tar.gz
$ cd debian ; HACK_AWAY
--- snip ---
I know that I could just download the tarball from github and use
git-import-orig to import the release, but I basically see upstream as simply
another remote branch whose tags are packaged. I would welcome any feedback,
criticism and praise for this workflow.
This, however, raises some questions:
1. What to do for new releases/tags?
i. One way would be to run "git-import-orig --uscan" and be done with it, but I
would probably lose all upstream history on the upstream branch if I do that.
ii. Another way would simply merge the remote changes into 'upstream' and
'debian' and basically boils down to:
$ git fetch UPSTREAM_GH_USER
$ git checkout upstream ; git merge UPSTREAM_GH_USER/master
$ git checkout master ; git merge NEW_TAG_TO_PACKAGE
$ uscan --rename
$ pristine-tar commit ../foo_NEW_TAG_TO_PACKAGE.orig.tar.gz
$ cd debian ; HACK_AWAY
2. How to repack tarballs/tags? (DFSG, etc)
I am really not sure how to repack tarballs in this workflow which might be
needed to make it DFSG compliant or simply because some files should not be
shipped. (jars for Java for example). My feeling is that I'd have to work on
the actual tarball acquired with uscan and repack it, before commiting to the
pristine-tar branch.
There are also some helper that can be incorporated into the watch file (such
as jh_repack), which would essentially mean that the tarball does *not*
correspond to an upstream tag. It also seems to be good practice to implement
get-orig-source in the rules file, in which the repacking could also happen.
3. Repository overkill
The packaging should probably be pushed to a git repo on alioth, which would
mean that "master" and "pristine-tar" track the alioth repo, and "upstream"
needs to be pushed explicitly to alioth as it tracks the upstream repository.
This difference in the branch setup is a potential source of error and I would
like to avoid it, but am not sure how.
In short
--------
Am I nuts?
What are your workflows?
Do you *only* work with tarballs and don't use/track the upstream repositories at all?
* only use git-import-orig
* Repository lives only on alioth and all branches track alioth
If not: How do you work with the *real* upstream branches? How do you generate
tarballs?
Sorry for the wall-of-text and for all your advice in advance :)
--
.''`. Wolodja Wentland <babilen@gmail.com>
: :' :
`. `'` 4096R/CAF14EFC
`- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
Attachment:
signature.asc
Description: Digital signature