Bug 248967 - USE_GITLAB lacking support for tags
Summary: USE_GITLAB lacking support for tags
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-28 13:12 UTC by phryk-ports
Modified: 2020-09-02 13:05 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description phryk-ports 2020-08-28 13:12:50 UTC
`USE_GITHUB` has `GH_TAGNAME` while `USE_GITLAB` has no equivalent. This should be added to make porters' lives easier.

Super bonus points for adding something like GL_SIGNING_FINGERPRINT or similar for verifying signatures of cryptographically signed releases. ;)

PS: Like usual, I'm not sure if this is the right category to report this in, but haven't found anything more fitting. ¯\_(ツ)_/¯
Comment 1 Mathieu Arnold freebsd_committer 2020-08-28 13:38:26 UTC
Well, github supports fetching a just-in-time archive using a commit hash or a tag, gitlab puts the full commit hash is present in the resulting archive in the directory name, so, you need to provide that commit hash anyway.
Comment 2 phryk-ports 2020-08-28 13:47:08 UTC
(In reply to Mathieu Arnold from comment #1)

This isn't true:
https://gitlab.com/sequoia-pgp/sequoia/-/archive/v0.19.0/sequoia-v0.19.0.tar.gz
points to a tagged release only via the tag name "v0.19.0" and even when untaring it, the commit hash doesn't show up anywhere, far as I can tell.

Maybe you're referring to older gitlab behavior?
Comment 3 Mathieu Arnold freebsd_committer 2020-09-02 13:05:43 UTC
Well, this is not true for gitlab.com that runs the latest gitlab version, but until all the Gitlab instances have migrated to the new url scheme, we do have to keep the old behavior.

Nothing is preventing work on also supporting the newer download scheme though.