.spec file Source0 magic for github release source tarballs?

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/23/2014 05:49 PM, Adam Williamson wrote:
> 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.
> 

Actually, it's not a problem with tarballs. That's *precisely* why we
store the tarball hashes. This way, we at least know whether they
still match.

And it's still possible to 'ninja' a github repository with a history
rewrite (for example if the upstream discovers that they have content
that was impermissible to distribute, they might retroactively delete
if from the history). This would change all git hashes that occur
after this time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLiZvsACgkQeiVVYja6o6Pe0wCeNUI3x2sa0br+2qMs2MLmL2yX
GvsAni3A4//1e5s+hXhbUlh75gtpqazp
=fSzG
-----END PGP SIGNATURE-----