.spec file Source0 magic for github release source tarballs?

Adam Williamson awilliam at redhat.com
Thu Jan 23 22:49:20 UTC 2014


On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote:
> On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý <msuchy at redhat.com>
> wrote:
>         On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote:
>         >
>         > Take, for example,
>         https://github.com/nfs-ganesha/nfs-ganesha/releases, where
>         there's a button for "Source code
>         > (tar.gz)" pointing at
>         https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz
>         >
>         > Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz.
>         >
>         > If I click on that link the downloaded file is named
>         nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition
>         http
>         > header.
>         >
>         > Likewise if I use `curl -L ...` the downloaded file is named
>         nfs-ganesha-2.0.0.tar.gz.
>         >
>         > But for my nfs-ganesha.spec file, if I use the github link
>         shown above, I have to load a file V2.0.0.tar.gz into the
>         > look-aside cache. Anything else and rpm and rpmlint whine.
>         >
>         > Is there a best practice here that I'm missing?
>         
>         
>         https://fedoraproject.org/wiki/Packaging:SourceURL#Github
> 
> 
> 
> 
> Interesting... However, if you're working with an actual release tag,
> I would think Peter's method would be much better.

It is a good idea to use a specific commit as your source, not a tag,
because the tag can be silently edited, and then you lose source
reproducibility.

Yes, this is a problem with tarballs too - upstream can always ninja the
tarball - but look at it this way: github affords us the ability to
avoid that problem, and so we should take it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net



More information about the devel mailing list