Re: Fix mk/fetch/github.mk

[Thomas Klausner <wiz%gatalith.at@localhost>]

On Tue, Feb 13, 2024 at 08:07:04PM -0500, Greg Troxel wrote:
> I think there is a release tarball if you don't try to do anything
> special that is just like a tag tarball.  But, not our problem at least
> today.

True, the tag tarball is the default distfile.

> Are we having collisions between sha-1 hashes and tags?  If not, what is
> colliding?  I have so far not absorbed the original problem.

I haven't completely understood it either - I remember having seen
this before adam@ met it again. Perhaps moved tags so that the release
doesn't match the tag any longer?

> > This is the usual expansion when you use v${PKGVERSION_NOREV} and what
> > url2pkg provides - I don't think anyone adds these manually.
> 
> Do you mean nobody adds refs/tags manually?

Yes. I noticed that url2pkg adds "refs/tags/" to the GITHUB_TAG, but I
never do.

> I have a fuzzy memory of having to add refs/tags to GITHUB_TAG for
> something to get it to download a tag tarball.  Or maybe I was just
> making it match the URL that I grabbed from my browser from a download
> link.

I guess the latter.

> Do we think that v${PKGVERSION_NOREV} and refs/tags/v${PKGVERSION_NOREV}
> are usually equivalent?

Yes.

> What are the canonical download URLs for tags and commit hashes?
> 
> With the recent change, unison-snapshot tries to fetch:
> 
>   https://github.com/bcpierce00/unison/archive/refs/tags/d9bb5734b802b23e1ca3553fdeb8e2d15d45e0ac.tar.gz
> 
> which fails.  With up-to-date pkgsrc, it succeeds in fetching
> 
>   Requesting https://github.com/bcpierce00/unison/archive/d9bb5734b802b23e1ca3553fdeb8e2d15d45e0ac.tar.gz
>   Redirected to https://codeload.github.com/bcpierce00/unison/tar.gz/d9bb5734b802b23e1ca3553fdeb8e2d15d45e0ac
> 
> With lensfun, I see
> 
>   Requesting https://github.com/lensfun/lensfun/archive/v0.3.4.tar.gz
>   Redirected to https://codeload.github.com/lensfun/lensfun/tar.gz/refs/tags/v0.3.4
>   Requesting https://codeload.github.com/lensfun/lensfun/tar.gz/refs/tags/v0.3.4
> 
> So it seems there is "tar.gz" for commit hashes and "refs/tags" for
> tags.

Both URLs contain 'tar.gz'. It seems to be 'tar.gz/' for commit hashes
and 'tar.gz/refs/tags/' for tags.

> I am suggesting to encode GITHUB_TAG vs GITHUB_HASH in packages, so that
> we can adapt the fetch logic over time to fetch those kinds of things,
> which are logically separate.
> 
> Right now we have a mix of objects in TAG.  A path could be:
> 
>   add GITHUB_HASH (and document of course)
> 
>   enhance url2pkg to choose HASH/TAG correctly
> 
>   flip packages with commit hashes to GITHUB_HASH
> 
>   change fetch url for GITHUB_TAG
> 
> which should result in relatively little breakage.

Sounds good to me!
Possibly make pkglint warn if it thinks the GITHUB_TAG is a commit hash.
 Thomas