pkgsrc-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: pkgsrc/mk



On Sat, Mar 07, 2015 at 02:17:52PM +0000, Tobias Nygren wrote:
> Module Name:  pkgsrc
> Committed By: tnn
> Date:         Sat Mar  7 14:17:52 UTC 2015
> 
> Modified Files:
>       pkgsrc/mk: bsd.pkg.mk
>       pkgsrc/mk/fetch: bsd.fetch-vars.mk bsd.fetch.mk
> Added Files:
>       pkgsrc/mk/fetch: github.mk
> 
> Log Message:
> Adopt USE_GITHUB from FreeBSD ports to make github MASTER_SITE
> handling less painful.
> See: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github
> 
> To use, set in Makefile:
> 
> DISTNAME=     exampleproject-1.2
> USE_GITHUB=   YES
> 
> The following variables alter USE_GITHUB behavior:
> 
> GH_ACCOUNT    defaults to PKGBASE
> GH_PROJECT    defaults to PKGBASE
> GH_TAGNAME    defaults to PKGVERSION_NOREV
>               (sometimes you want to override with v${PKGVERSION_NOREV})
> GH_COMMIT     explicit commit hash if no tag is available
> GH_RELEASE    default empty, may be set to ${DISTNAME} for example
> GH_TYPE               overrides the autodetected MASTER_SITE URL scheme

I wish this had been discussed prior to bringing in - it's an infrastructure
change, and so would have been nice to talk about various issues I have with this
when not in reactionary mode.

So let's get to them here:

1. I like the functionality, HATE the names and the way of doing it

2. the GH_* names should be expanded to be GITHUB_*. BUT...

3.  Why do we have the GH_* defs in the first place if they're
defaulting to other defs we already have?  They're useless (except
maybe for GITHUB_COMMIT, but there HAS to be a better name for it than
that), invade our namespace, and add no value.

4. USE_GITHUB. "YES". Binary definition. Hate the way this is done.
Can't we key off MASTER_SITE_GITHUB or similar?

Now don't get me wrong, I like the functionality. But we've diverged so
far from FreeBSD's ports that compatibility is not an argument that could
be delivered with a straight face, and I dislike going back to the mass
of twee, incomprehensible, and one-off definitions that this is bringing
back repressed memories :(

Best,
Alistair



Home | Main Index | Thread Index | Old Index