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.
Although I should pipe it through gzip/bzip2 :-/
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Associate Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc.