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): > > > > On 2023/11/13 13:49:03 +0100, Stefan Hagen > > > > <sh+openbsd-po...@codevoid.de> wrote: > > > > > DIST_TUPLE did not yet make it into the Makefile.template. > > > > > > > > > > OK to add it under the GH_ parts? > > > > > > > > why not replacing GH_* completely with this in the template? There is > > > > still stuff that explicitly depends on GH_*? (except go.port.mk) > > > > > > If there's no case left for GH_, I'm not against removing it. > > > > to be clear: I wasn't suggesting to nuke GH_*, just that the Makefile > > template could mention only one method, and DIST_TUPLE is IMHO the one > > to suggest now. > > Neither was I. I was speaking in the context of the Makefile.template
agreed. > > here it still references GH_* directly, not that's bad, but I'd take the > > chance to generalize a bit this paragraph and providing a note that can > > be used to quickly fetch stuff from various forges. > > > 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. > > > +#DIST_TUPLE = forgename account project tagname/commitid . > > No explanation about the last parameter? > > I'd leave the concrete example in, I think it helps. I also added the > "autogenerated" word, which I find useful, because it's not really clear > what's meant with a non-static tarball if one doesn't know about the > checksum problem already. > > 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 13 Nov 2023 18:53:15 > -0000 > @@ -36,17 +36,12 @@ 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. I think it's useful to show the /releases/ and /archive/ directories here, I think I would say something along these lines # /releases/ -> preferred. ignore DIST_TUPLE, just use SITES and DISTNAME. # /archive/ -> autogenerated tarball. use DIST_TUPLE. > -# 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 > +# 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? > +#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.
