Hello Sérgio,

On Sat, Jan 9, 2016 at 7:08 AM, Sérgio Basto sergio@serjux.com wrote:

Hi,

On Sáb, 2015-12-26 at 04:39 +0000, Sérgio Basto wrote:

...

Hi, At list for github we can remove ".tar.gz#" [1] may (or should) I update the wiki ?

-Source0: https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D.tar.gz #/%{name}-%{shortcommit0}.tar.gz +Source0: https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D/%%7Bname }-%{shortcommit0}.tar.gz

I think was Germano that found this formula, previous email demonstrate that works for commit revision but also works for git tags and releases. Instead source url be like this : https://github.com/besser82/pipelight-selinux/archive/v0.3.1.tar.gz#/pi pelight-selinux-0.3.1.tar.gz https://github.com/besser82/pipelight-selinux/archive/v0.3.1.tar.gz#/pipelight-selinux-0.3.1.tar.gz

Could be like this: https://github.com/besser82/pipelight-selinux/archive/v0.3.1/pipelight- selinux-0.3.1.tar.gz https://github.com/besser82/pipelight-selinux/archive/v0.3.1/pipelight-selinux-0.3.1.tar.gz

It could be even like this: https://github.com/besser82/pipelight-selinux/archive/v0.3.1.tar.gz which is more natural looking at the archives page https://github.com/besser82/pipelight-selinux/releases

Previously, there was a bit vague wording at [1] which raised questions, you can see the difference here [2]. "For a number of reasons (immutability, availability, uniqueness), you must use the full commit revision hash when referring to the sources" looked like a requirement to use commit hashes all the time. Now it's gone so we can rely on the statement "If the upstream does create tarballs you should use them as tarballs provide an easier trail for people auditing the packages", assuming that GitHub created that archive for us. Sure, it doesn't create it in advance but since it generates it properly (preserving file modification time, and such) we can consider it as an ordinary static tarball.

[1] https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Services

[2] https://fedoraproject.org/w/index.php?title=Packaging:SourceURL&diff=nex...

On 1/9/2016 11:08 AM, Dave Johansen wrote:

On Fri, Jan 8, 2016 at 6:08 PM, Sérgio Basto <sergio@serjux.com mailto:sergio@serjux.com> wrote:

Hi,

On Sáb, 2015-12-26 at 04:39 +0000, Sérgio Basto wrote:
> Hi,
> At list for github we can remove ".tar.gz#" [1] may (or should) I
> update the wiki ?
>
> -Source0:
https://github.com/OWNER/%{name}/archive/%{commit0}.tar.gz
<https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D.tar.gz>
> #/%{name}-%{shortcommit0}.tar.gz
> +Source0:
https://github.com/OWNER/%{name}/archive/%{commit0}/%{name
<https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D/%%7Bname>
> }-%{shortcommit0}.tar.gz

I think was Germano that found this formula, previous email
demonstrate
that works for commit revision but also works for git tags and
releases.
Instead source url be like this :
https://github.com/besser82/pipelight-selinux/archive/v0.3.1.tar.gz#/pi
pelight-selinux-0.3.1.tar.gz
<https://github.com/besser82/pipelight-selinux/archive/v0.3.1.tar.gz#/pi%0Apelight-selinux-0.3.1.tar.gz>

Could be like this:
https://github.com/besser82/pipelight-selinux/archive/v0.3.1/pipelight-
selinux-0.3.1.tar.gz
<https://github.com/besser82/pipelight-selinux/archive/v0.3.1/pipelight-%0Aselinux-0.3.1.tar.gz>

The previous discussion brought up that while tags shouldn't change, nothing enforces that and some upstreams might do that. That was the major argument for using the commit that corresponds to the tag instead of the tag itself.

Upstreams could just as easily replace a simple tarball on a site as well though. It seems like there should be a certain level of sanity-expectation for what upstreams are doing, and if it violates generally-expected norms then to call that out as such.

If no release tags are ever made, that's one thing... but it feels like if a release tag is present we should be using that.

-jc