Re: Packaging Go Libs

[Steven Hartland]

I saw that, hoping it goes well as all of the other tools we've tried have
fairly significant issues.

On Sat, 13 May 2017 at 12:55, Christian Schwarz  wrote:

> Side note: There is an ongoing effort to build a dependency manager
> that aims at becoming part of the official Golang toolchain:
>
> https://github.com/golang/dep
>
> Cheers,
>
>   Christian
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Packaging Go Libs

[Christian Schwarz]

Side note: There is an ongoing effort to build a dependency manager
that aims at becoming part of the official Golang toolchain:

https://github.com/golang/dep

Cheers,

  Christian


signature.asc
Description: This is a digitally signed message part

Re: Packaging Go Libs

[Derek (freebsd lists)]

Agree with previous sentiments, and:

On 17-04-18 10:59 PM, Christopher Hall wrote:

You should use built in golang vendoring to ensure these
dependencies, as their is no guarantee that someone won't update the
library port and your app would break, so doing that is very fragile


Currently the GH_TUPLE method is working as it specifies exact
dependency versions or specific git hashes.

but we made several attempts at submodules in vendor dir
but have had problems building and go get -u breaks things.

I am wondering if you might suggest a tool or do any other programs in
ports use such a dependency tool.  Last time I searched ports tree I
only saw GH_TUPLE used so I just followed that method.



From my point of view, the only thing that should be in the 
vendor directory on checkout is the version-lock file.  This is 
different for different tools.


I have been using gb, as it makes the most sense to me:

https://getgb.io/

sysutils/hfm uses this

godep is also popular, from what I understand:

https://godoc.org/github.com/tools/godep

Vendoring changed internally in go with a GO15VENDOREXPERIMENT 
build environment variable (and then default in 1.6), although I 
have not yet played with it:


https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo/edit

... from the docs, it sounds like it would be compatible with gb 
from a build standpoint - and you simply could use gb to track, 
fetch and lock versions in development - the same thing the ports 
GH_TUPLE covers.  What you do when it's not hosted at github, 
well


Derek

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Packaging Go Libs

[Christopher Hall]

Hello Steven,

On Tue, 18 Apr 2017 13:09:22 +, Steven Hartland
<kill...@multiplay.co.uk> wrote:

> You should use built in golang vendoring to ensure these
> dependencies, as their is no guarantee that someone won't update the
> library port and your app would break, so doing that is very fragile

Currently the GH_TUPLE method is working as it specifies exact
dependency versions or specific git hashes.

but we made several attempts at submodules in vendor dir
but have had problems building and go get -u breaks things.

I am wondering if you might suggest a tool or do any other programs in
ports use such a dependency tool.  Last time I searched ports tree I
only saw GH_TUPLE used so I just followed that method.

> On Tue, 18 Apr 2017 at 03:34, Christopher Hall <
> christopherhall@gmail.com> wrote:  
> 
> > Hello Steve,
> >
> > On Mon, 17 Apr 2017 10:20:20 -0400, Steve Wills <st...@mouf.net>
> > wrote: 
> > > Hi,
> > >
> > > I'd like to propose eliminating packaging of Go libs.  
> >
> > For my own go application I use the ports mechanism to specify
> > specific versions of dependencies and it would only have been
> > tested with those; if forces to use an older version it would
> > likely fail as the APIs on some libs have changed quite a lot.
> >
> > So I personally see no need to have any go dependencies in the ports
> > tree. I currently like the idea of having all the go dependencies
> > statically linked and only few external "C" libs as dynamic links
> > as it makes packaging and deployment very quick.
> >  
> > >
> > > Almost every Go app is developed with a different version of any
> > > given lib than what another Go app might use. Forcing a Go app to
> > > use a different version than what upstream might have chosen is
> > > error prone at best and likely to produce a build that's
> > > unsupported upstream. So for the packaged libs to even be useful,
> > > we would have to have as many versions of each lib as there are
> > > consumers, or nearly as many.
> > >
> > > Further, best practice in the Go community is for Go apps to
> > > vendor all their dependencies and almost all apps do that. This
> > > is the reason most Go apps use different versions of it's libs.
> > >
> > > So to me, packaging Go libs doesn't make sense and I think we
> > > should remove the Go libs from ports.
> > >
> > > Existing ports which use the Go libs should be updated to not use
> > > the Go lib ports by doing one of these, in priority order:
> > >
> > > * Converted to using vendored deps included with the package
> > > source if possible (preferred)
> > > * Fetching the versions of deps specified by upstream (in the
> > > case of vendor.json)
> > > * As a last resort (deps are not included nor versions specified
> > > exactly) fetching versions of deps available at the time of
> > > upstream development
> > >
> > > Further, documentation should be added to the Porters Handbook
> > > saying that we don't package Go libs and portlint should be
> > > updated to check for installing files in GO_SRCDIR and GO_LIBDIR
> > > (exceot lang/go*).
> > >
> > > For reference, here's the list of Go lib ports that I found at the
> > > moment:
> > >
> > > archivers/go-compress
> > > databases/gomdb
> > > databases/gosqlite3
> > > databases/levigo
> > > databases/radix.v2
> > > databases/redigo
> > > devel/go-bayesian
> > > devel/go-cobra
> > > devel/go-codec
> > > devel/go-cpuid
> > > devel/go-crc32
> > > devel/go-faker
> > > devel/go-form
> > > devel/go-go.uuid
> > > devel/go-goregen
> > > devel/go-hashicorp-logutils
> > > devel/go-json-rest
> > > devel/go-logrus
> > > devel/go-metrics
> > > devel/go-nuid
> > > devel/go-pflag
> > > devel/go-protobuf
> > > devel/go-raw
> > > devel/go-runewidth
> > > devel/go-slices
> > > devel/go-sql-driver
> > > devel/go-uuid
> > > devel/go-yaml
> > > devel/goprotobuf
> > > net/go-amqp
> > > net/go-geoip
> > > net/go-httppath
> > > net/go-httptreemux
> > > net/go-nats
> > > net/go.net
> > > security/go.crypto
> > > security/goptlib
> > > textproc/go.text
> > > www/go-fasthttp
> > > www/webgo
> > >
> > > Does anyone have any objection or reasoning why this doesn't make
> > > sense?
> > >
> > > Thanks,
> > > Steve
> > >  
> >
> >
> > --
> > Best Regards.
> > Christopher Hall.
> > ___
> > freebsd-ports@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> > To unsubscribe, send any mail to
> > "freebsd-ports-unsubscr...@freebsd.org" 


-- 
Best Regards.
Christopher Hall.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Packaging Go Libs

[Steve Wills]

I've thought about that or perhaps a quick script to turn a vendor.json
in the the appropriate GH_TUPLE for a port Makefile, but even that seems
less necessary these days as more and more projects included a vendor
dir in their source tree.

Thanks to everyone for their input, seems we all agree, so I'll go ahead
with this plan.

Thanks,
Steve

On 04/18/2017 10:24, Julien Laffaye wrote:
> I agree with you.
> Maybe we should provide helpers to do the "fetching dependencies" part so
> that will be less cumbersome.
> 
> On Mon, Apr 17, 2017 at 4:20 PM, Steve Wills <st...@mouf.net> wrote:
> 
>> Hi,
>>
>> I'd like to propose eliminating packaging of Go libs.
>>
>> Almost every Go app is developed with a different version of any given
>> lib than what another Go app might use. Forcing a Go app to use a
>> different version than what upstream might have chosen is error prone at
>> best and likely to produce a build that's unsupported upstream. So for
>> the packaged libs to even be useful, we would have to have as many
>> versions of each lib as there are consumers, or nearly as many.
>>
>> Further, best practice in the Go community is for Go apps to vendor all
>> their dependencies and almost all apps do that. This is the reason most
>> Go apps use different versions of it's libs.
>>
>> So to me, packaging Go libs doesn't make sense and I think we should
>> remove the Go libs from ports.
>>
>> Existing ports which use the Go libs should be updated to not use the Go
>> lib ports by doing one of these, in priority order:
>>
>> * Converted to using vendored deps included with the package source if
>> possible (preferred)
>> * Fetching the versions of deps specified by upstream (in the case of
>> vendor.json)
>> * As a last resort (deps are not included nor versions specified
>> exactly) fetching versions of deps available at the time of upstream
>> development
>>
>> Further, documentation should be added to the Porters Handbook saying
>> that we don't package Go libs and portlint should be updated to check
>> for installing files in GO_SRCDIR and GO_LIBDIR (exceot lang/go*).
>>
>> For reference, here's the list of Go lib ports that I found at the moment:
>>
>> archivers/go-compress
>> databases/gomdb
>> databases/gosqlite3
>> databases/levigo
>> databases/radix.v2
>> databases/redigo
>> devel/go-bayesian
>> devel/go-cobra
>> devel/go-codec
>> devel/go-cpuid
>> devel/go-crc32
>> devel/go-faker
>> devel/go-form
>> devel/go-go.uuid
>> devel/go-goregen
>> devel/go-hashicorp-logutils
>> devel/go-json-rest
>> devel/go-logrus
>> devel/go-metrics
>> devel/go-nuid
>> devel/go-pflag
>> devel/go-protobuf
>> devel/go-raw
>> devel/go-runewidth
>> devel/go-slices
>> devel/go-sql-driver
>> devel/go-uuid
>> devel/go-yaml
>> devel/goprotobuf
>> net/go-amqp
>> net/go-geoip
>> net/go-httppath
>> net/go-httptreemux
>> net/go-nats
>> net/go.net
>> security/go.crypto
>> security/goptlib
>> textproc/go.text
>> www/go-fasthttp
>> www/webgo
>>
>> Does anyone have any objection or reasoning why this doesn't make sense?
>>
>> Thanks,
>> Steve
>>
>>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 



signature.asc
Description: OpenPGP digital signature

Re: Packaging Go Libs

[Julien Laffaye]

I agree with you.
Maybe we should provide helpers to do the "fetching dependencies" part so
that will be less cumbersome.

On Mon, Apr 17, 2017 at 4:20 PM, Steve Wills <st...@mouf.net> wrote:

> Hi,
>
> I'd like to propose eliminating packaging of Go libs.
>
> Almost every Go app is developed with a different version of any given
> lib than what another Go app might use. Forcing a Go app to use a
> different version than what upstream might have chosen is error prone at
> best and likely to produce a build that's unsupported upstream. So for
> the packaged libs to even be useful, we would have to have as many
> versions of each lib as there are consumers, or nearly as many.
>
> Further, best practice in the Go community is for Go apps to vendor all
> their dependencies and almost all apps do that. This is the reason most
> Go apps use different versions of it's libs.
>
> So to me, packaging Go libs doesn't make sense and I think we should
> remove the Go libs from ports.
>
> Existing ports which use the Go libs should be updated to not use the Go
> lib ports by doing one of these, in priority order:
>
> * Converted to using vendored deps included with the package source if
> possible (preferred)
> * Fetching the versions of deps specified by upstream (in the case of
> vendor.json)
> * As a last resort (deps are not included nor versions specified
> exactly) fetching versions of deps available at the time of upstream
> development
>
> Further, documentation should be added to the Porters Handbook saying
> that we don't package Go libs and portlint should be updated to check
> for installing files in GO_SRCDIR and GO_LIBDIR (exceot lang/go*).
>
> For reference, here's the list of Go lib ports that I found at the moment:
>
> archivers/go-compress
> databases/gomdb
> databases/gosqlite3
> databases/levigo
> databases/radix.v2
> databases/redigo
> devel/go-bayesian
> devel/go-cobra
> devel/go-codec
> devel/go-cpuid
> devel/go-crc32
> devel/go-faker
> devel/go-form
> devel/go-go.uuid
> devel/go-goregen
> devel/go-hashicorp-logutils
> devel/go-json-rest
> devel/go-logrus
> devel/go-metrics
> devel/go-nuid
> devel/go-pflag
> devel/go-protobuf
> devel/go-raw
> devel/go-runewidth
> devel/go-slices
> devel/go-sql-driver
> devel/go-uuid
> devel/go-yaml
> devel/goprotobuf
> net/go-amqp
> net/go-geoip
> net/go-httppath
> net/go-httptreemux
> net/go-nats
> net/go.net
> security/go.crypto
> security/goptlib
> textproc/go.text
> www/go-fasthttp
> www/webgo
>
> Does anyone have any objection or reasoning why this doesn't make sense?
>
> Thanks,
> Steve
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Packaging Go Libs

[Steven Hartland]

You should use built in golang vendoring to ensure these dependencies, as
their is no guarantee that someone won't update the library port and your
app would break, so doing that is very fragile
On Tue, 18 Apr 2017 at 03:34, Christopher Hall <
christopherhall@gmail.com> wrote:

> Hello Steve,
>
> On Mon, 17 Apr 2017 10:20:20 -0400, Steve Wills <st...@mouf.net> wrote:
>
> > Hi,
> >
> > I'd like to propose eliminating packaging of Go libs.
>
> For my own go application I use the ports mechanism to specify specific
> versions of dependencies and it would only have been tested with those;
> if forces to use an older version it would likely fail as the APIs on
> some libs have changed quite a lot.
>
> So I personally see no need to have any go dependencies in the ports
> tree. I currently like the idea of having all the go dependencies
> statically linked and only few external "C" libs as dynamic links as it
> makes packaging and deployment very quick.
>
> >
> > Almost every Go app is developed with a different version of any given
> > lib than what another Go app might use. Forcing a Go app to use a
> > different version than what upstream might have chosen is error prone
> > at best and likely to produce a build that's unsupported upstream. So
> > for the packaged libs to even be useful, we would have to have as many
> > versions of each lib as there are consumers, or nearly as many.
> >
> > Further, best practice in the Go community is for Go apps to vendor
> > all their dependencies and almost all apps do that. This is the
> > reason most Go apps use different versions of it's libs.
> >
> > So to me, packaging Go libs doesn't make sense and I think we should
> > remove the Go libs from ports.
> >
> > Existing ports which use the Go libs should be updated to not use the
> > Go lib ports by doing one of these, in priority order:
> >
> > * Converted to using vendored deps included with the package source if
> > possible (preferred)
> > * Fetching the versions of deps specified by upstream (in the case of
> > vendor.json)
> > * As a last resort (deps are not included nor versions specified
> > exactly) fetching versions of deps available at the time of upstream
> > development
> >
> > Further, documentation should be added to the Porters Handbook saying
> > that we don't package Go libs and portlint should be updated to check
> > for installing files in GO_SRCDIR and GO_LIBDIR (exceot lang/go*).
> >
> > For reference, here's the list of Go lib ports that I found at the
> > moment:
> >
> > archivers/go-compress
> > databases/gomdb
> > databases/gosqlite3
> > databases/levigo
> > databases/radix.v2
> > databases/redigo
> > devel/go-bayesian
> > devel/go-cobra
> > devel/go-codec
> > devel/go-cpuid
> > devel/go-crc32
> > devel/go-faker
> > devel/go-form
> > devel/go-go.uuid
> > devel/go-goregen
> > devel/go-hashicorp-logutils
> > devel/go-json-rest
> > devel/go-logrus
> > devel/go-metrics
> > devel/go-nuid
> > devel/go-pflag
> > devel/go-protobuf
> > devel/go-raw
> > devel/go-runewidth
> > devel/go-slices
> > devel/go-sql-driver
> > devel/go-uuid
> > devel/go-yaml
> > devel/goprotobuf
> > net/go-amqp
> > net/go-geoip
> > net/go-httppath
> > net/go-httptreemux
> > net/go-nats
> > net/go.net
> > security/go.crypto
> > security/goptlib
> > textproc/go.text
> > www/go-fasthttp
> > www/webgo
> >
> > Does anyone have any objection or reasoning why this doesn't make
> > sense?
> >
> > Thanks,
> > Steve
> >
>
>
> --
> Best Regards.
> Christopher Hall.
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Packaging Go Libs

[Christopher Hall]

Hello Steve,

On Mon, 17 Apr 2017 10:20:20 -0400, Steve Wills <st...@mouf.net> wrote:

> Hi,
> 
> I'd like to propose eliminating packaging of Go libs.

For my own go application I use the ports mechanism to specify specific
versions of dependencies and it would only have been tested with those;
if forces to use an older version it would likely fail as the APIs on
some libs have changed quite a lot.

So I personally see no need to have any go dependencies in the ports
tree. I currently like the idea of having all the go dependencies
statically linked and only few external "C" libs as dynamic links as it
makes packaging and deployment very quick.

> 
> Almost every Go app is developed with a different version of any given
> lib than what another Go app might use. Forcing a Go app to use a
> different version than what upstream might have chosen is error prone
> at best and likely to produce a build that's unsupported upstream. So
> for the packaged libs to even be useful, we would have to have as many
> versions of each lib as there are consumers, or nearly as many.
> 
> Further, best practice in the Go community is for Go apps to vendor
> all their dependencies and almost all apps do that. This is the
> reason most Go apps use different versions of it's libs.
> 
> So to me, packaging Go libs doesn't make sense and I think we should
> remove the Go libs from ports.
> 
> Existing ports which use the Go libs should be updated to not use the
> Go lib ports by doing one of these, in priority order:
> 
> * Converted to using vendored deps included with the package source if
> possible (preferred)
> * Fetching the versions of deps specified by upstream (in the case of
> vendor.json)
> * As a last resort (deps are not included nor versions specified
> exactly) fetching versions of deps available at the time of upstream
> development
> 
> Further, documentation should be added to the Porters Handbook saying
> that we don't package Go libs and portlint should be updated to check
> for installing files in GO_SRCDIR and GO_LIBDIR (exceot lang/go*).
> 
> For reference, here's the list of Go lib ports that I found at the
> moment:
> 
> archivers/go-compress
> databases/gomdb
> databases/gosqlite3
> databases/levigo
> databases/radix.v2
> databases/redigo
> devel/go-bayesian
> devel/go-cobra
> devel/go-codec
> devel/go-cpuid
> devel/go-crc32
> devel/go-faker
> devel/go-form
> devel/go-go.uuid
> devel/go-goregen
> devel/go-hashicorp-logutils
> devel/go-json-rest
> devel/go-logrus
> devel/go-metrics
> devel/go-nuid
> devel/go-pflag
> devel/go-protobuf
> devel/go-raw
> devel/go-runewidth
> devel/go-slices
> devel/go-sql-driver
> devel/go-uuid
> devel/go-yaml
> devel/goprotobuf
> net/go-amqp
> net/go-geoip
> net/go-httppath
> net/go-httptreemux
> net/go-nats
> net/go.net
> security/go.crypto
> security/goptlib
> textproc/go.text
> www/go-fasthttp
> www/webgo
> 
> Does anyone have any objection or reasoning why this doesn't make
> sense?
> 
> Thanks,
> Steve
> 


-- 
Best Regards.
Christopher Hall.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Packaging Go Libs

[Steven Hartland]

Agreed we shouldn't vendor go libraries

On Mon, 17 Apr 2017 at 15:20, Steve Wills <st...@mouf.net> wrote:

> Hi,
>
> I'd like to propose eliminating packaging of Go libs.
>
> Almost every Go app is developed with a different version of any given
> lib than what another Go app might use. Forcing a Go app to use a
> different version than what upstream might have chosen is error prone at
> best and likely to produce a build that's unsupported upstream. So for
> the packaged libs to even be useful, we would have to have as many
> versions of each lib as there are consumers, or nearly as many.
>
> Further, best practice in the Go community is for Go apps to vendor all
> their dependencies and almost all apps do that. This is the reason most
> Go apps use different versions of it's libs.
>
> So to me, packaging Go libs doesn't make sense and I think we should
> remove the Go libs from ports.
>
> Existing ports which use the Go libs should be updated to not use the Go
> lib ports by doing one of these, in priority order:
>
> * Converted to using vendored deps included with the package source if
> possible (preferred)
> * Fetching the versions of deps specified by upstream (in the case of
> vendor.json)
> * As a last resort (deps are not included nor versions specified
> exactly) fetching versions of deps available at the time of upstream
> development
>
> Further, documentation should be added to the Porters Handbook saying
> that we don't package Go libs and portlint should be updated to check
> for installing files in GO_SRCDIR and GO_LIBDIR (exceot lang/go*).
>
> For reference, here's the list of Go lib ports that I found at the moment:
>
> archivers/go-compress
> databases/gomdb
> databases/gosqlite3
> databases/levigo
> databases/radix.v2
> databases/redigo
> devel/go-bayesian
> devel/go-cobra
> devel/go-codec
> devel/go-cpuid
> devel/go-crc32
> devel/go-faker
> devel/go-form
> devel/go-go.uuid
> devel/go-goregen
> devel/go-hashicorp-logutils
> devel/go-json-rest
> devel/go-logrus
> devel/go-metrics
> devel/go-nuid
> devel/go-pflag
> devel/go-protobuf
> devel/go-raw
> devel/go-runewidth
> devel/go-slices
> devel/go-sql-driver
> devel/go-uuid
> devel/go-yaml
> devel/goprotobuf
> net/go-amqp
> net/go-geoip
> net/go-httppath
> net/go-httptreemux
> net/go-nats
> net/go.net
> security/go.crypto
> security/goptlib
> textproc/go.text
> www/go-fasthttp
> www/webgo
>
> Does anyone have any objection or reasoning why this doesn't make sense?
>
> Thanks,
> Steve
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Packaging Go Libs

[Steve Wills]

Hi,

I'd like to propose eliminating packaging of Go libs.

Almost every Go app is developed with a different version of any given
lib than what another Go app might use. Forcing a Go app to use a
different version than what upstream might have chosen is error prone at
best and likely to produce a build that's unsupported upstream. So for
the packaged libs to even be useful, we would have to have as many
versions of each lib as there are consumers, or nearly as many.

Further, best practice in the Go community is for Go apps to vendor all
their dependencies and almost all apps do that. This is the reason most
Go apps use different versions of it's libs.

So to me, packaging Go libs doesn't make sense and I think we should
remove the Go libs from ports.

Existing ports which use the Go libs should be updated to not use the Go
lib ports by doing one of these, in priority order:

* Converted to using vendored deps included with the package source if
possible (preferred)
* Fetching the versions of deps specified by upstream (in the case of
vendor.json)
* As a last resort (deps are not included nor versions specified
exactly) fetching versions of deps available at the time of upstream
development

Further, documentation should be added to the Porters Handbook saying
that we don't package Go libs and portlint should be updated to check
for installing files in GO_SRCDIR and GO_LIBDIR (exceot lang/go*).

For reference, here's the list of Go lib ports that I found at the moment:

archivers/go-compress
databases/gomdb
databases/gosqlite3
databases/levigo
databases/radix.v2
databases/redigo
devel/go-bayesian
devel/go-cobra
devel/go-codec
devel/go-cpuid
devel/go-crc32
devel/go-faker
devel/go-form
devel/go-go.uuid
devel/go-goregen
devel/go-hashicorp-logutils
devel/go-json-rest
devel/go-logrus
devel/go-metrics
devel/go-nuid
devel/go-pflag
devel/go-protobuf
devel/go-raw
devel/go-runewidth
devel/go-slices
devel/go-sql-driver
devel/go-uuid
devel/go-yaml
devel/goprotobuf
net/go-amqp
net/go-geoip
net/go-httppath
net/go-httptreemux
net/go-nats
net/go.net
security/go.crypto
security/goptlib
textproc/go.text
www/go-fasthttp
www/webgo

Does anyone have any objection or reasoning why this doesn't make sense?

Thanks,
Steve



signature.asc
Description: OpenPGP digital signature