Packaging Go Libs

Steven Hartland killing at multiplay.co.uk
Mon Apr 17 16:13:52 UTC 2017


Agreed we shouldn't vendor go libraries

On Mon, 17 Apr 2017 at 15:20, Steve Wills <steve at 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
>
>


More information about the freebsd-ports mailing list