bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Leo Famulari <leo@famulari.name>]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

On Mon, May 29, 2017 at 03:48:36AM +0530, Arun Isaac wrote:
> 
> >> Could you switch to upstream's github release tarball instead?
> >> https://github.com/asciinema/asciinema/archive/v1.4.0.tar.gz
> >>
> >> LGTM, otherwise!
> >
> > Is there a reason to prefer one over the other?
> >
> > I ask because, typically, these unammed GitHub tarballs are not actual
> > releases prepared by the maintainers, but just a snapshot of the Git
> > repo, created automatically by GitHub for each tag. PyPi tends to
> > contain the "real" release in cases like this.
> 
> I thought it is better to depend directly on the upstream source
> (github, in this case) than on an intermediary (pypi) who has also
> packaged the software. If we use pypi, Guix becomes some kind of second
> order package repository that depends on pypi, the primary package
> repository. WDYT?

My understanding is that project maintainers upload their releases to
PyPi, not that PyPi packages the release for them. Is that incorrect?

The GitHub tarballs that are named like 'v$version.tar.gz' are not
releases made by the upstream projects. Take flex as an example:

https://github.com/westes/flex/releases/tag/v2.6.4

The file 'flex-2.6.4.tar.gz' is a release tarball prepared by the flex
maintainer.

The link to 'Source code (tar.gz)' leads to 'v2.6.4.tar.gz', which is a
snapshot of the tagged commit, created automatically by GitHub. It's not
prepared by the maintainer, and it can't be built in the normal way
because it hasn't been bootstrapped. It may be missing things like
special documentation, NEWS, etc. Also, there may be extraneous
development files included in the snapshot.

In general, I think we should avoid the GitHub snapshots unless there is
nothing else to use. In this case, is there something wrong with the
release uploaded to PyPi?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]