Dear all,
I am trying to create a debian package with 3 golang executables that share the same golang library. My directory contains the following files:
rtd_dsp.go an executable that shows streaming measurements on the commandline
rtd_web.go an executable that shows last measurement via webserver
rtd_influxdb.go an executable that stores streaming measurements into a database
dmn.go library code including listener for multiple measurement streams
The executables can be easily created as follows:
go build rtd_dsp.go dmn.go
go build rtd_web.go dmn.go
go build rtd_influxdb.go dmn.go
I found the debian package dh-golang for creating debian packages, and am trying to get that working. However, it seems not as simple as advertised, it complains about a number of things after creating a debian folder with the required changelog, control, copyright and rules, source/target files and running dpkg-buildpackage -us -uc -d using dh-golang 1.48 on Ubuntu 20.04.2 (with golang-1.16):
that it cannot find the external packages, while they are available for grabs in $(GOMODCACHE)=$(HOME)/go/pkg/mod, in my view it can either get them itself or re-use the available ones. As an experiment I modified golang.pm to set the GOPATH to the $(GOMODCACHE).
that it cannot find any Go files, while are just available in the created _build/src/sst-goflow directory.
I expected an error that the executable go files each implement the same handleMessage call (as a simple go install indicates), while I would want it to create separate executables
Is there an easier way to create a debian package with golang executables? And/or are the above problems easy to solve?
I managed to find a simpler solution using the debian/install file and a regular gnu Makefile with a build target to create the executables. The install file is used to copy the executables to usr/bin in the debian package. So no dh-golang for me anymore until someone can convince me otherwise;-)
I don’t know gh-golang at all and thus cannot say anything about it, but if the regular Debian way of building an install package works, then I would not look further.
The static nature of Go binaries (that is, no shared lib dependencies) makes it particularly easy to package and deploy Go binaries without the need for specialized tools.
This being said, there are always convenience options like goreleaser available. (Especially with the NFPM option.)
This might be because underscore characters in Go source file names have a special meaning: words after the underscore have to be build tag names. For example, a file named myfile_windows.go will only build when GOOS=windows. myfile_linux_386.go will only build when GOOS=linux and GOARCH=386, etc. Maybe try removing the underscore from the go source file names to see if the behavior changes.
Hi Christoph,
Thanks for your reply, I’ll have a look at goreleaser / NFPM, I hope it is not overkill in contrast to my current solution;-)
I met some problems with debian/install on embedded targets, but this could be mitigated for now by not stripping the debug symbols from the binaries. I opened a debian dpkg-dev ticket to hopefully solve this properly.
Kind regards,
Dennis
Hehe, yes, goreleaser might be overkill. The basics are easy (I wrote about them here) but bringing the backends (NFPM, Fury.io,…) up and running looks a bit more involving. I think where goreleaser shines is inside a CI/CD pipeline.