Creating debian package with golang executables sharing same go library

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 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?

Kind regards,


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;-)

Kind regards,

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,

Hehe, yes, goreleaser might be overkill. The basics are easy (I wrote about them here) but bringing the backends (NFPM,,…) up and running looks a bit more involving. I think where goreleaser shines is inside a CI/CD pipeline.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.