On 02/16/2011 12:22 AM, BJ Dierkes wrote:
Hello all,
I hope I am not the first to come across packaging issues for projects that use GitHub as
their upstream source download. For those not familiar, GitHub dynamically generates
downloads for all git 'tags'. So for example:
$ git tag -a -m 'Tagging 1.0.0' 1.0.0
This would create a tag of '1.0.0' in git. On GitHub, this tag would be
'downloadable' via a dynamic app such as:
https://github.com/derks/myapp/zipball/1.0.0
This is the upstream URL that a lot of GitHub users are providing rather than a direct
download link. Unfortunately the above is not usable by RPM because rpmbuild expects the
URL to end with the file. If I were to use the above in my spec, I would get an error
saying something to the affect of 'unknown source file 1.0.0'. Additionally, the
tarbal that is created looks like:
myapp-1.0.0-XXXXXXX.tar.gz
Where XXXXXXX is the last bit of the git commit hash id... which cause yet another pain
in that... you need to update this commit revision every time you update the spec... and
it just makes things a bit less fluid. I'm wondering how other people have resolved
these issues for projects using GitHub as the upstream Source0 download provider.
Finally, debian has a web app to resolve these issues at:
http://githubredir.debian.net/
What would be the thoughts of using that to produce more sane/traditional tarbals of
upstream GitHub source?
What I am using in my spec files is something like this:
# git clone
git://github.com/sonatype/sisu
# git archive --prefix="sonatype-sisu-1.4.3.2/" --format=tar \
# sisu-1.4.3.2 > sisu-1.4.3.2.tar.gz
Source0: %{name}-%{version}.tar.gz
Which basically takes the tag name and creates a nice tarball from it.
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Associate Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc.
http://cz.redhat.com