Re: Fix mk/fetch/github.mk

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

On Tue, Feb 13, 2024 at 06:39:03PM -0500, Greg Troxel wrote:
> Overall, my impressions are (and they are a little fuzzy):
> 
>   GITHUB_TAG should only be used for things that are actual git tags
> 
>   GITHUB_HASH (bikeshed, making that up) should be used for things that
>   are (currently SHA-1) commit hashes
> 
>   I am unclear on if there is anything else.

Github tags and releases are different things.

Tags are the result of 'git tag' and a push of the tag to github.  The
downloaded tarball for that is a snapshot of the git repository.

On the github web frontend you can make a release (based on a tag),
which allows you to add release notes and also upload separate
tarballs (which might include e.g. autoconf-generated files) - and
these tarballs are the files that are fetched by the pkgsrc
infrastructure.

The names of the tags and releases can be arbitrarily set, but there
are conventions - usually "${PKGREVSION}" or "v${PKGVERSION}" which is
why your list looks the way it looks.

The download URL logic (on the github side, I think, not sure about
that) automatically expands some values. And in very rare cases, that
is not unique, which is what adam's commit tries to address.

>   1187 v${PKGVERSION_NOREV}
>    159 ${PKGVERSION_NOREV}
>     57 ${DISTNAME}
>     34 v${VERSION}
>     20 refs/tags/v${PKGVERSION_NOREV}

This is the usual expansion when you use v${PKGVERSION_NOREV} and what
url2pkg provides - I don't think anyone adds these manually.

>     13 release-${PKGVERSION_NOREV}

As I mentioned, conventions only... (more like that skipped).

So yes, there's at least three things - tags, releases, and git commit hashes.

Hope this helps,
 Thomas