Re: What to do about github (dynamic) downloads

[Filip Hajny <filip%joyent.com@localhost>]

> 10. 8. 2017 v 13:40, Greg Troxel <gdt%lexort.com@localhost>:
> 
> 
> "J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> 
>> There are probably at least two kinds of downloads available from
>> GitHub, then.  (There may be more; I don't know.)  I don't know anything
>> about this dynamic packaging via codeload.github.com, but I do know that
>> GitHub has the concept of a "release" for which the project owner can
>> provide links to binary files.  See:
>> 
>>  https://help.github.com/articles/about-releases/
>> 
>> Google's Protobuf project, for example, uses this:
>> 
>>  https://github.com/google/protobuf/releases
>> 
>> There's a "Downloads" section for each release which contains links to
>> many binary files (e.g., .tar.gz, .zip).  I'm 99% sure these are not
>> dynamically generated on the fly; they're just binary files available
>> for download.
>> 
>> So, if there would be any avoidance policy, I think it should be at a
>> finer-grained level than the service level.  In other words, binary
>> files associated with a GitHub release should be fine.  They are
>> different from whatever these dynamically generated archives are from
>> codeload.github.com.
> 
> Thanks - that's useful to understand.
> 
> I wonder if we are having problems with things that are actually
> "releases".  One of the problems of the modern condition is people
> thinking that software doesn't need releases, and this could all be a
> symptom of that.

More on that note, in the above example of protobuf: The links with the ‘package’ icon (and ‘/release/‘ in the URL) point to binary releases files, which in my understanding need to be provided by the project staff. The few with the ‘zip’ icon (and ‘/archive/‘ in the URL) are auto-generated by Github every time you git-tag a repo. The latter case is much more common, and a majority of Github projects only provide these (possibly in connection to the standpoint suggested by Greg, that software doesn’t need releases).

In case GNU configure is used in the particular software, the true releases usually come with ‘configure’ generated, whereas with the ‘archive’ code snapshots you need to use autoconf first, so the former are preferable in my view. Either of them beats having to pin point a particular commit and stamp with it with a date string on our end.

I believe the original issue raised by John was about the difference between the upstream site release tarballs and the files available on Github. Since I don’t see any of the release-release links on github.com/bitcoin/bitcoin/, I assume the developer didn’t bother to upload the existing binary files, but rather relied on Github pre-creating the files based on Git tags, hence a different gzip/tar rendition.

-F