On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote: > On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý <msu...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
