Agreed. But the difference is that using full commits a history rewrite will always be detected. Using a tag is making it possible for upstream to bind the same tag to a different commit. And since it's possible, it will happen.
It's a shame there is no way to block forced updates on github. It's a little bit to easy to make a history rewrite there.On Fri, Jan 24, 2014 at 2:13 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
-----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@xxxxxxxxxx> 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-----
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
