On Fri, Dec 14, 2018 at 10:44 AM Ronny Bangsund <ronny.bangs...@gmail.com> wrote:
> Which Unix/derivative? The great thing about them is that they have so > many standards to choose from ;) > Linux, and it should support the FHS :) > > "go build" isn't sufficient for most of my projects, if I want proper > distribution of binaries. I might use "go generate" to create some > data/source a program depends on, and I always embed the version tag as > returned by "git describe --tags <branch> --abbrev=0" in the binaries with > the -X flag. That requires a build script of some sort. > Yeah, that too. > > If you package with any common Linux distro's tools it's expected that the > packager has a full build environment. It would of course be useful if you > included a script to "go get" everything the build needs, and that can > usually be done in pre-build hooks in these packaging systems. > Right, but the thing is - distribution packagers may be OK to have to do some adjustments; I mainly want to target users who want to build and install the tool "just like any other tool". Basically, the user shouldn't notice that it's written in Go - it shouldn't be weird compared to anything else they compile and install. > > If you're building server apps maybe you'd consider packaging as > containers instead. If they're command line tools you're still going to > have to consider the target OS and its conventions, but you can make the > binary quite self-sufficient with per-platform source files or/and go > generated settings, so that they look for or create a configuration file. > > I don't think the packaging itself is a problem, as there are tools like > dh-make-golang to massage Go into Debian-derivative packages. You just need > to specify and dependencies like databases, discovery services and so on > you require. > dh-make-golang is actually a good hint, I'll have to check what that does - whether that e.g. uses something like I want, or contains all logic in itself. > > For my own stuff I make the programs themselves flexible enough that there > aren't any hard requirements for configuration files and their locations, > but Linux builds have a fallback to /etc/<appname>/ for server stuff, > $HOME/.<appname>/ for CLI tools, and macOS builds use > $HOME/Library/Application Support/<appname>/. I always leave in the option > to specify an alternative path via -C or --config. > Even with that, I still want an install procedure that supports stuff like --prefix and installs there. Config files indeed are the smallest problem (and if I want, I can even rely on XDG for their locations rather than using the --prefix). > > The config files define where to load all the other data and any logging > options (/var/ and /log/ are possibilities there). > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/ycHR0LkdhL0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- No need to handle this message off-hours. E-Mail isn't realtime communication. IM if urgent. Default Borgmon graphs to Dygraph: go/nebgua-dygraph-extension No more "borgcfg production/borg/.../foo.borg update"! Just run uborgcfg! go/uborgcfg -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
