.spec file Source0 magic for github release source tarballs?
leamas.alec at gmail.com
Tue Jan 21 17:25:12 UTC 2014
Actually, the GL are pretty clear here: the source should be referenced
using the full commit, nothing else. There is some reasoning why. The tag
should got to Version: (as long its 'sane').
Besides that this is the existing GL, there is also a subtle difference in
git-archive (which supposedly runs this). When archiving a tag, the
sources gets today's date. OTOH, when archiving a commit, the sources
modification dates are their commit date. Last time I checked this was also
true on github.
On Tue, Jan 21, 2014 at 6:09 PM, Richard Shaw <hobbes1069 at gmail.com> 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
>> > 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
>> > 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?
> Interesting... However, if you're working with an actual release tag, I
> would think Peter's method would be much better.
> 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