[arch-general] What's the best way of packaging golang packages?
Hi, I'm not familiar with go, but I'm trying to use some go programs, caddy for example. I read the PKGBUILD of it. It first use `go get' to get the dependencies and then do the `go build'. However, I don't think it a good practice. I'm used to the way of installing the dependency packages first, then install the target package. Python packages are packaged this way. On the other hand, go packages has its features. Go programs are compiled to a single binary that do not link to other go libraries, so they doesn't depend on other go packages. I also read the Debian Go Packaging document ( https://pkg-go.alioth.debian.org/packaging.html), but I still don't know when and why we need to make a go package. I'm also confused when I see node.js packages. I see many of the packages are built using just an `npm install' so the packaging process will pull a lot of code, but I think it's better than that in go because the node.js packages are installed in the user home so that it won't be installed again when another node.js package needs the same dependency. Thanks, Iru -- Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument/
On 17-03-09 00:13:59, Iru Cai via arch-general wrote:
Go programs are compiled to a single binary that do not link to other go libraries, so they doesn't depend on other go packages.
You answered your question here, haven't you?
I'm also confused when I see node.js packages. I see many of the packages are built using just an `npm install' so the packaging process will pull a lot of code, but I think it's better than that in go because the node.js packages are installed in the user home so that it won't be installed again when another node.js package needs the same dependency.
Are you saying that building a go program should re-use user-installed go packages? Does https://wiki.archlinux.org/index.php/Go_package_guidelines answer your question? -- Pierre Neidhardt
Sorry for replying so late but I've just seen this mail.
On Thu, Mar 9, 2017 at 12:25 AM, Pierre Neidhardt
On 17-03-09 00:13:59, Iru Cai via arch-general wrote:
Go programs are compiled to a single binary that do not link to other go libraries, so they doesn't depend on other go packages.
You answered your question here, haven't you?
That's what I think of go packages. They don't depend on any other go packages, but actually the source code of a lot of go packages depend on other source packages.
I'm also confused when I see node.js packages. I see many of the packages are built using just an `npm install' so the packaging process will pull a lot of code, but I think it's better than that in go because the node.js packages are installed in the user home so that it won't be installed again when another node.js package needs the same dependency.
Are you saying that building a go program should re-use user-installed go packages?
Yes, that's my point. I don't like to use `go get` to get other source code that doesn't belong to the packaged software and is not in PKGBUILD. Also, if I build go packages without internet access (e.g. in Open Build System), I can't build this package.
Does https://wiki.archlinux.org/index.php/Go_package_guidelines answer your question?
-- Pierre Neidhardt
-- Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument/
Sources have to be fetched online at some point anyways. If Internet goes out after you've fetched the sources, then you can still build the packages. Regarding user packages: it is not a good idea to use them in PKGBUILDs for several reasons, first one being that the user is free to change the source code of Go package locally (change branch, change code). The PKGBUILD must be reproduicible, so it's better to start afresh. -- Pierre Neidhardt
On 2017-03-08 17:13, Iru Cai via arch-general wrote:
Hi,
I'm not familiar with go, but I'm trying to use some go programs, caddy for example. I read the PKGBUILD of it. It first use `go get' to get the dependencies and then do the `go build'.
Yes, that's a bad practice, and the fact that devtools allow network access during build doesn't help. How Debian and Fedora handles it (and we should too) is packaging source code that is later being used by the compiler. Semi-example of that can be found in go-tools[1] package, except golang.org/x/net should be effectively a standalone package and a make dependency. The other way is asking upstream to vendor their dependencies in git repository so we don't need to handle it at all. Bartłomiej
On 2017-03-21 11:14, Bartłomiej Piotrowski wrote:
On 2017-03-08 17:13, Iru Cai via arch-general wrote:
Hi,
I'm not familiar with go, but I'm trying to use some go programs, caddy for example. I read the PKGBUILD of it. It first use `go get' to get the dependencies and then do the `go build'.
Yes, that's a bad practice, and the fact that devtools allow network access during build doesn't help.
How Debian and Fedora handles it (and we should too) is packaging source code that is later being used by the compiler. Semi-example of that can be found in go-tools[1] package, except golang.org/x/net should be effectively a standalone package and a make dependency.
The other way is asking upstream to vendor their dependencies in git repository so we don't need to handle it at all.
Bartłomiej
And here's the missing link... [1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag...
Many Go tools have fairly generic names. Aren't you afraid of a (possibly future) naming conflicts by placing them all in /usr/bin/? -- Pierre Neidhardt
On 2017-03-21 11:47, Pierre Neidhardt wrote:
Many Go tools have fairly generic names. Aren't you afraid of a (possibly future) naming conflicts by placing them all in /usr/bin/?
-- Pierre Neidhardt
We can detect this, we have the technology… So until that happens, I will rest easily. Bartłomiej
participants (3)
-
Bartłomiej Piotrowski
-
Iru Cai
-
Pierre Neidhardt