.spec file Source0 magic for github release source tarballs?
leamas.alec at gmail.com
Fri Jan 24 16:51:20 UTC 2014
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
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 at redhat.com>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 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/
> -----END PGP SIGNATURE-----
> devel mailing list
> devel at lists.fedoraproject.org
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel