Stuart Henderson wrote (2023-11-13 21:01 CET): > On 2023/11/13 20:10, Stefan Hagen wrote: > > Omar Polo wrote (2023-11-13 18:07 CET): > > > On 2023/11/13 14:57:39 +0100, Stefan Hagen <sh+openbsd-po...@codevoid.de> > > > wrote: > > > > Omar Polo wrote (2023-11-13 14:08 CET): > > > > > > Here's what I had in mind. it needs better wording but haven't come up > > > with something better yet. Neither "forgename" nor "name" (nor "forge") > > > convey the meaning of "just put github/codeberg/gitlab/... here". > > > > > +# For web forges (github, codeberg, ...) if there's a static tarball > > > +# available (preferred) just use SITES and DISTNAME, otherwise > > > +# DIST_TUPLE, in which case DISTNAME is not generally needed. > > > > Are these sites called "forge"? It's the first time I hear "forgename". > > It's clear from the context and I'm not against it. Intuitively I'd call > > it sitename. > > > > I like your wording. I'd either still reference dist-tupple.pattern > > somewhere or include the full list. > > > > > -# github: > > > -# /releases/ -> preferred. ignore GH_*, just use SITES and DISTNAME. > > > -# /archive/ -> GH_ACCOUNT and GH_PROJECT, plus either GH_TAGNAME or > > > GH_COMMIT. > > > > I think it's useful to show the /releases/ and /archive/ directories > here, I think I would say something along these lines
The example works for github, gitlab and codeberg. It does not apply to kde, gnome and sourcehut. > > +# For web forges (codeberg, github, gitlab, kde, srht, gnome) if there's > > +# a static tarball available (preferred) just use SITES and DISTNAME. > > +# For autogenerated ones use DIST_TUPLE, in which case DISTNAME is not > > +# generally needed. > > I don't like the word "forge" here, I don't think it's all that well > known and there's potential for confusion with sourceforge. Is it enough > to just list the names? What about calling them platforms? > > +#DIST_TUPLE = forgename account project tagname/commitid extractdir > > +#DIST_TUPLE = github vim vim v9.0.1677 . > > perhaps showing an example here that uses a second DIST_TUPLE entry > pointed at a subdir would be helpful. I think I found a way to describe it in a way that reads good and is understandable and contains all the information and is accurate. Sorry to come up with a completely different version, but I think it's better. And assuming that dist_tuple will be used a lot, it's probably fine to give it a bit more space in the file. Is it good? Index: infrastructure/templates/Makefile.template =================================================================== RCS file: /cvs/ports/infrastructure/templates/Makefile.template,v diff -u -p -u -p -r1.99 Makefile.template --- infrastructure/templates/Makefile.template 15 Oct 2023 11:22:01 -0000 1.99 +++ infrastructure/templates/Makefile.template 14 Nov 2023 07:29:51 -0000 @@ -36,17 +36,19 @@ DISTNAME = ??? #PKGNAME-foo = ??? for multi packages # -# github: -# /releases/ -> preferred. ignore GH_*, just use SITES and DISTNAME. -# /archive/ -> GH_ACCOUNT and GH_PROJECT, plus either GH_TAGNAME or GH_COMMIT. +# On source code hosting platforms use static tarballs over generated ones. +# It's easy to distinguish between them on github, gitlab and codeberg by +# looking at the file URL: +# /releases/ -> preferred. Use SITES and DISTNAME. +# /archive/ -> use DIST_TUPLE (use only if there is no release version). # -# set DISTNAME if using GH_COMMIT, or if using GH_TAGNAME and the tag is not in -# the format "v1.00" or "1.00". -# -#GH_ACCOUNT = username -#GH_PROJECT = project -#GH_TAGNAME = 1.0 -#GH_COMMIT = abab123456789abacafeabab123123b1e4ble4bl +# platform: codeberg, github, gitlab, kde, srht, gnome +# account: usually the account or organisation name +# project: the project or repository name +# tagname: source code tag like 1.0.1 or v1.0 (more creative tags require DISTNAME) +# commitid: at least 10 charactes of the commit hash (requires DISTNAME) +# subdir: usually ".", can be a subdir if the archive extracts to the root +#DIST_TUPLE = platform account project tagname/commitid subdir # for any port that creates shared libraries. # both libtool and cmake automatically set filenames based on this variable.
