On Fri, Dec 14, 2018 at 10:44 AM Ronny Bangsund
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 --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// for server stuff,
> $HOME/./ for CLI tools, and macOS builds use
> $HOME/Library/Application Support//. 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.
