Date: Mon, 17 Apr 2017 10:20:20 -0400 From: Steve Wills <steve@mouf.net> To: ports@FreeBSD.org Subject: Packaging Go Libs Message-ID: <e34c63fd-8b3d-3bb3-7375-58631b33a50a@mouf.net>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kU5nhC6ioid4Mtl5TlMOPFjFePKmgugtf Content-Type: multipart/mixed; boundary="b12e4lu4voqAVnfQXne3xANmcROjOiR13"; protected-headers="v1" From: Steve Wills <steve@mouf.net> To: ports@FreeBSD.org Message-ID: <e34c63fd-8b3d-3bb3-7375-58631b33a50a@mouf.net> Subject: Packaging Go Libs --b12e4lu4voqAVnfQXne3xANmcROjOiR13 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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 --b12e4lu4voqAVnfQXne3xANmcROjOiR13-- --kU5nhC6ioid4Mtl5TlMOPFjFePKmgugtf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGjBAEBCgCNFiEEmPpBSlwqDvnP0K0N9c9isyB7G6EFAlj0zyZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk4 RkE0MTRBNUMyQTBFRjlDRkQwQUQwREY1Q0Y2MkIzMjA3QjFCQTEPHHN0ZXZlQG1v dWYubmV0AAoJEPXPYrMgexuh7oIH/jh7kDFjgn9BrveOt5r4fvJGeaHoTHi9LMN+ d45YQ0S2Chfoyjz9aksgPrnzov6sDlECi0Xgpx9Pck3cwdRTdooIaRVs2i+msuM9 X1fQNHD4+cNoljFuWNMoAyT3FHXQPyBO6xDaeFt9Dcnp4hMzYdTCnXoQdInQTK/1 LjIw6DFuweKLxVx6ziOeeAx90DKeJrF5gK/VcmBmbjHY32+9ZujF2AQnT3u4LOJD LSQW+cQ1dfgvRsBVQim+hJAGWGPgsFtRi32hkrXCmxPVxfjJx1W3FWbntOoNowfF p1jdrEKP7eS0AUbxfInyOVVy/9p73N79o8A6jVWwzdFfNLSDN8c= =hSQe -----END PGP SIGNATURE----- --kU5nhC6ioid4Mtl5TlMOPFjFePKmgugtf--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e34c63fd-8b3d-3bb3-7375-58631b33a50a>