.spec file Source0 magic for github release source tarballs?
awilliam at redhat.com
Sat Jan 25 00:57:41 UTC 2014
On Fri, 2014-01-24 at 08:13 -0500, Stephen Gallagher wrote:
> >> 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.
It's still better to avoid the problem than to know it exists...I don't
think we disagree, I'm just explaining why (I think) it's a good idea to
use a commit ID for a github project even if a tarball is available.
> 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.
Sure, possible, but probably less common than people doing 'silent'
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
More information about the devel