Quoting Mattias Ellert (2013-05-31 13:18:31)
tor 2013-05-30 klockan 11:51 +0200 skrev Björn Esser:
>
> I'd say "NO WAY", because tags can be created/deleted/altered by
anyone
> having write-access to the repo. They are NOT explicitly meant to be
> created-once-lasts-forever or points-to-same-commit-sha-forever, so
> checking the tarball to be pristine might be close to impossible in the
> future, if the tag will be altered pointing to an other commit or be
> deleted. This may lead to FTBFS as well.
Why is a tarball published on github less valuable than a tarball
published anywhere else?
Admittedly, as you say a tag in github can be removed and reapplied
again on a different commit. However, a well behaving upstream will not
do this. This is not something unique to github - the same can happen on
a git server somewhere else and in svn and cvs too. Also a tarball
published by upstream on a separate server can be replaced with a
different one if upstream is not well behaved. If you do not accept the
tarball generated from the github tag published on the github server,
why would you accept any source tarball published anywhere? They both
can be replaced at any time by a weirdly behaving upstream. And neither
will be replaced by a well behaving one.
Rearranged a bit, agree completely with Mattias. Github is no different than
other places in this regard.
> An URL like this also _WILL_
> lead to conflicting names of source-tarballs, because it's only named to
> the version and not to the app's name. Don't forget the naming
> guidelines: "When naming a package, the name should match the upstream
> tarball or project..."
That guideline actually refers to name of (s)rpms not some tarball in lookaside
cache, but OK I'm game...
Easily solvable. Example:
Source0:
https://github.com/JodaOrg/%{name}/archive/v%{version}.tar.gz#/%{name}-{v...
Note the ending "#/%{name}-%{version}.tar.gz".
As a bonus there's not dirhash to deal with. In the past problem with that URL
has been that they didn't have static hash. That has been fixed as well I believe.
>
https://fedoraproject.org/wiki/Packaging:NamingGuidelines?rd=Packaging/Na...
>
> So using the URL from the guidelines all will be fine, because it will
> create a tarball named containing the projectname, version and the
> definitive unique and forever-lasting commit-sha...
I actually had a ticket opened at FPC[1] to update this guideline but then I
haven't found time to prepare the draft. If someone would create a proposal and
reopen the ticket...we might improve the situation.
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc.
http://cz.redhat.com