On 2018/02/27 13:39, Landry Breuil wrote:
> On Tue, Feb 27, 2018 at 12:28:07PM +0000, Stuart Henderson wrote:
> > Many ports are using github's on-the-fly generated source-code tarballs
> > via the GH_ variables in Makefiles.
> >
> > These are *not* guaranteed to be stable, they can change as github
> > update software and caches expire (this has happened at some point over
> > the last few months so we have been seeing a number of hash failures
> > recently). Due to local caches at the github clusters, these files
> > can be different depending on which cluster you're connecting to,
> > so if you regenerate distinfo to match the file which you see
> > locally, it may cause breakage elsewhere in the world.
> >
> > : "It is not meant to be reliable or a way to distribute software
> > : releases and nothing in the software stack is made to try to
> > : produce consistent archives."
> >
> > Sometimes upstream *only* provides these auto generated files, but in
> > other cases they use github's releases infrastructure and upload "normal"
> > generated distfiles which are not then subject to change.
> >
> > To identify this, go to the project's "releases" page.
> > Using an example of a port I've just fixed:
> >
> > https://github.com/rdoeffinger/iec16022/releases/.
> >
> > Under "Assets" on this page, you might see files with a "box" icon
> > which are uploads.
> >
> > On the iec16022 page I'm using as an example, Assets has these:
> >
> > iec16022-0.3.0.exe <- uploaded windows binary
> > iec16022-0.3.0.tar.xz <- uploaded source tarball
> > iec16022-0.3.0.tar.xz.asc <- uploaded gpg sig
> > Source code (zip) <- auto generated
> > Source code (tar.gz) <- auto generated
> >
> > If there are only entries for "Source code (zip)" and "Source code
> > (tar.gz)" the only options are to use GH_TAGNAME or ask upstream to
> > upload a file.
> >
> > But in the case above, a proper distfile is available, so I've
> > switched the graphics/iec16022 port across to use it.
> >
> > This is done by avoiding the GH_* variables and reducing the amount
> > of magic in the ports Makefile: just use DISTNAME and MASTER_SITES
> > as standard, and set HOMEPAGE if needed (it's provided automatically
> > when GH_* are set).
>
> So that gives, for audio/cantata:
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/audio/cantata/Makefile,v
> retrieving revision 1.11
> diff -u -r1.11 Makefile
> --- Makefile 3 Jan 2018 08:02:26 -0000 1.11
> +++ Makefile 27 Feb 2018 12:37:18 -0000
> @@ -2,9 +2,11 @@
>
> COMMENT = Qt-based MPD client
>
> -GH_ACCOUNT= CDrummond
> -GH_PROJECT= cantata
> -GH_TAGNAME= v2.2.0
> +V = 2.2.0
> +DISTNAME = cantata-${V}
> +MASTER_SITES = https://github.com/CDrummond/cantata/releases/download/v${V}/
> +EXTRACT_SUFX = .tar.bz2
> +HOMEPAGE = https://github.com/CDrummond/cantata
>
> CATEGORIES = audio
>
> Index: distinfo
> ===================================================================
> RCS file: /cvs/ports/audio/cantata/distinfo,v
> retrieving revision 1.3
> diff -u -r1.3 distinfo
> --- distinfo 3 Jan 2018 08:02:26 -0000 1.3
> +++ distinfo 27 Feb 2018 12:37:18 -0000
> @@ -1,2 +1,2 @@
> -SHA256 (cantata-2.2.0.tar.gz) = AA96hWFmf8jRX607i/CtqPaTp2/tCvr6FmoCJcyT6d4=
> -SIZE (cantata-2.2.0.tar.gz) = 2955660
> +SHA256 (cantata-2.2.0.tar.bz2) = yEaR6xdxERjTxRLXDLQiJn96E3KQCCzdH/CocbSo5cA=
> +SIZE (cantata-2.2.0.tar.bz2) = 2251649
>
> Does this look right ?
That looks right though I would probably bump REVISION to be safe.
> Is there a way to make it look nicer ? GH_ACCOUNT &
> GH_PROJECT is useful to avoid repeating values....
I had a play with bsd.port.mk to look at doing this with an additional
GH_ variable and keep using GH_ACCOUNT/PROJECT. I tried GH_RELEASE=<tag>
working similar to GH_TAGNAME, I also tried it reusing GH_TAGNAME and
adding GH_RELEASE=Yes as a flag.
The bsd.port.mk changes for those are easy, but when I tried documenting
them I found I couldn't come up with a simple and clear way to describe
them, which suggested that it would hard for other porters to grasp too :)
I'm open to suggestions, but my general feeling is that we're better off
with less rather than more magic.
No comments:
Post a Comment