[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/52747: new package submission for influxdb 1.4.2
The following reply was made to PR pkg/52747; it has been noted by GNATS.
From: Benny Siegert <bsiegert%gmail.com@localhost>
Cc: pkg-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, pkgsrc-bugs%netbsd.org@localhost,
Subject: Re: pkg/52747: new package submission for influxdb 1.4.2
Date: Tue, 9 Jan 2018 21:49:26 +0100
> However, after doing more research, I think that go software building =
> seems determined to operate in opposition to that concept: influxdb, for =
> example, has 20 or more dependencies, some of which are only available =
> as git checkouts (which is what the gdm tool is being used to fetch and =
> manage). Since each of those dependencies are based on a particular =
> commit id, I=E2=80=99m not sure that it would be feasible to create =
> packages for each dependency.=20
This has been done before, even though it is arguably quite tedious.
Look at the go-hugo package for inspiration.
I am working on https://github.com/bsiegert/gourl2pkg, which is not
quite finished but will at least tell you what the dependencies are.
> Would an acceptable alternative be to create a distribution file that =
> contained the particular go files required by a particular version of =
> influxdb and make that available on, say, GitHub? That way, a canonical =
> set of source would be available for download by pkgsrc and the build =
> could proceed without any additional network access?=
This would be somewhat questionable if not done by a developer.
You might try to get your upstream to vendor all dependencies, i.e.
put them in a vendor subdirectory. This is what Caddy has done, and it
has made packaging it trivial :)
Main Index |
Thread Index |