Re: Create influxdb package

[Attila Fülöp <attila%fueloep.org@localhost>]

On 1/15/19 2:46 AM, Greg Troxel wrote:
> But, another --- very slightly less rigid --- stance in pkgsrc is that
> packages that logically depend on other packages should actually depend
> on pkgsrc packages of them, instead of including their code and building
> it.  The point is that when the dependency package is updated, we know
> that the updated code is used by everything, rather than having copies
> all over the place that are not recorded by the packaging system.

While this sounds reasonable I don't think it's feasible for two
reasons. First, go packages tend to pull in a lot of dependencies, e.g.
influxdb pulls in >90 of them, so you'd end up with a lot of work.
Second, this would only work with legacy GOPATH mode, which will go away
sooner or later (and would require a rebuild of the dependant which
should now be handled inside pkgsrc). There are also problems with
different go packages requiring different version of the same dependency.

Given the good security record of go code, I don't see much benefit in
managing each dependency inside pkgsrc, and as far as I understand, it's
also not currently done.

>> As a side note, shouldn't we move this technical discussion to the
>> github branch, since I think most mailing list members aren't interested
>> in the details of go packaging?
> I'm not sure pkgsrc-users is appropriate, vs tech-pkg, but discussion
> of how to deal with go modules in a way  which meets pkgsrc norms
> (instead of the usual case of each language thinking they are the only
> thing that matters and inventing a new per-language packaging system
> that does not meet the no-build-download or one-copy norms :-) is
> definitely appropriate for pkgsrc lists.

OK, but since I expect this discussion to end soon, I'll leave it here.