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}-{version}.tar.gz 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/NamingGuidelines#General_Naming > > > > 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@xxxxxxxxxx> Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
