pkgsrc-Bugs archive

[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>
To: gnats-bugs%netbsd.org@localhost
Cc: pkg-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, pkgsrc-bugs%netbsd.org@localhost, 
	william%welliver.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 :)
 
 -- 
 Benny
 


Home | Main Index | Thread Index | Old Index