On 2023/11/14 08:42, Stefan Hagen wrote: > 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
All good up to here. > +# 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 This makes it seem like you have to use both e.g. "v1.23/ab5f63eb91". And actually you don't need to set DISTNAME with DIST_TUPLE and a commit id, though often you'd want to do so. For "more creative tags" you want to set PKGNAME but probably not DISTNAME. That's not what subdir is for - it is when you need to move the files after extracting. Truncated hashes don't work properly yet, WRKDIST isn't set correctly and subdir renaming doesn't work, so let's not suggest those yet. Can be changed later when they do. Maybe this? # id: either a tag name or commit hash. # tag names with standard tag formats, like 1.0.1 or v1.0, set an # appropriate PKGNAME automatically. otherwise, set it yourself. # "make show=PKGNAMES" will help identify if that's needed. # for a commit hash, use the full hash (not shortened), and set PKGNAME. # subdir: usually ".", otherwise the extracted files are moved to another # directory under WRKDIST. mostly useful for git submodules. #DIST_TUPLE = platform account project id subdir
