[opensuse-go] current guidlines for new go package
Hello! Being relatively new to packaging and for Go in particular, I'm looking into the possibilities of packaging dnscrypt-proxy [1] for openSUSE. The software is written in Go and depends on a bunch of other projects (approximately 25), that are included by upstream in the source code in a directory called "vendor". A small amount of these "dependencies" are already packaged in devel:languages:go, but mostly they are not directly available for openSUSE. Reading in the archive of this list for the months recently passed, do I understand correctly, that it is not necessary anymore to create a single package for each project the target package needs? A package for openSUSE is now allowed to include and use all repositories "vendored" by and in the upstream source code? (I'm not sure what "vendored" means exactly here.) What to do with dependencies, that are included in the source code, but also directly packaged for openSUSE? Which one to use/prefer in the build process? If the license differs between upstream and some of the included dependencies, which one should be mentioned in the spec file? All of them, only the license for the package the url points to? Do the naming conventions still apply, if all dependencies are resolved "inside" of the source package? Should the resulting package therefore be called "golang-github-jedisct1-dnscrypt-proxy", or, if it is not tied to devel:languages:go, simply "dnscrypt-proxy2" or "dnscrypt-proxy-go" (so does Archlinux)? Are both later mentioned naming options (those without golang-...) restricted to the resulting binary package? If someone can answer at least some of these questions, thank you very much! Please direct me to the right channel, if my questions are misplaced. All the best, cunix [1] https://github.com/jedisct1/dnscrypt-proxy -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
On 2018-04-04, cunix
The software is written in Go and depends on a bunch of other projects (approximately 25), that are included by upstream in the source code in a directory called "vendor".
A small amount of these "dependencies" are already packaged in devel:languages:go, but mostly they are not directly available for openSUSE.
Reading in the archive of this list for the months recently passed, do I understand correctly, that it is not necessary anymore to create a single package for each project the target package needs?
A package for openSUSE is now allowed to include and use all repositories "vendored" by and in the upstream source code? (I'm not sure what "vendored" means exactly here.)
What to do with dependencies, that are included in the source code, but also directly packaged for openSUSE? Which one to use/prefer in the build process?
If there is a vendor/ directory *always* use it. We are in the process of deleting all of the golang "library" packages, because they lead to confusion and were never really useful in the first place. If the project doesn't use vendor/, try to convince them to use it. While it is a huge pain if there's a security flaw in an underlying library, the downsides of one-package-per-golang-project are more significant.
If the license differs between upstream and some of the included dependencies, which one should be mentioned in the spec file? All of them, only the license for the package the url points to?
At the moment, legal has trouble with vendored repos (this is a problem that also exists in Rust and in the nodejs ecosystem). In short, you should probably just use the license of the top-level package. However, usually this results in Go packages requiring more legal review (it gets done manually) when you submit to Factory. In theory the License string should contain the licenses of all dependencies, but we don't have tooling to automate this sanely -- and adding all the licenses to the top-level might give the wrong impression of the project as a whole (think a GPLv3 project with MIT dependencies -- it's definitely not as simple as 'GPLv3 and MIT').
Do the naming conventions still apply, if all dependencies are resolved "inside" of the source package?
Should the resulting package therefore be called "golang-github-jedisct1-dnscrypt-proxy", or, if it is not tied to devel:languages:go, simply "dnscrypt-proxy2" or "dnscrypt-proxy-go" (so does Archlinux)?
Are both later mentioned naming options (those without golang-...) restricted to the resulting binary package?
The naming is also (mostly) optional. In general most binaries shouldn't be in devel:languages:go (you should submit them to the relevant project like network:tools or whatever), and you should name them something that users will be able to install sanely. golang-github-... honestly just leads to more frustration than its worth. A lot of the Go packaging guidelines were based on Ruby's, and I think most people have come to the realisation that those guidelines were quite a bit of a mistake. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
Hi cunix, welcome to the amazing world of go packaging :) On 04/04/2018 05:53 PM, cunix wrote:
Hello!
Being relatively new to packaging and for Go in particular, I'm looking into the possibilities of packaging dnscrypt-proxy [1] for openSUSE.
Our go packaging guidelines are in https://en.opensuse.org/openSUSE:Packaging_Go You can find the answer of most of your questions there. In any case, see my comments inline below:
The software is written in Go and depends on a bunch of other projects (approximately 25), that are included by upstream in the source code in a directory called "vendor".
pretty much like most of go applications out there :)
A small amount of these "dependencies" are already packaged in devel:languages:go, but mostly they are not directly available for openSUSE.
Reading in the archive of this list for the months recently passed, do I understand correctly, that it is not necessary anymore to create a single package for each project the target package needs?
Exactly. You only need to package the ones that provide binaries. Source code can be included as it is in upstream, meaning in the vendor directory.
A package for openSUSE is now allowed to include and use all repositories "vendored" by and in the upstream source code? (I'm not sure what "vendored" means exactly here.)
yes. "vendored" in your case means including the vendor directory from upstream.
What to do with dependencies, that are included in the source code, but also directly packaged for openSUSE? Which one to use/prefer in the build process?
just vendor your code and ignore the already packaged ones.
If the license differs between upstream and some of the included dependencies, which one should be mentioned in the spec file? All of them, only the license for the package the url points to?
All of them. And make sure the licenses are "right", meaning they are all open source and can be bundled together.
Do the naming conventions still apply, if all dependencies are resolved "inside" of the source package?
Should the resulting package therefore be called "golang-github-jedisct1-dnscrypt-proxy", or, if it is not tied to devel:languages:go, simply "dnscrypt-proxy2" or "dnscrypt-proxy-go" (so does Archlinux)?
if you plan to submit the package to devel:languages:go, yes you should apply the convention. Otherwise, feel free to use whatever name you like.
Are both later mentioned naming options (those without golang-...) restricted to the resulting binary package?
only if you plan to submit to devel:languages:go.
If someone can answer at least some of these questions, thank you very much!
you are welcome.
Please direct me to the right channel, if my questions are misplaced.
All the best, cunix
by the way this looks very cool :) -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
Cunix:
Hello!
[...] By replying to myself I want to thank you, Aleksa and Jordi, in one mail for your prompt and comprehensive answers to all of my questions. While I've looked at https://en.opensuse.org/openSUSE:Packaging_Go I wasn't sure if it is exactly up to date and some used terms, e. g. "library" in the context of go packaging, are now better understood with your answers.
From the point of a packager it is nice to hear, that time can be spend immediately on the target package instead of having to create a lot of needed other packages before. Your answers regarding licenses seem to differ slightly, but as I understand, this will be decided (in case of a factory submit request) by legal review. No matter which way is chosen in the beginning, it will be corrected anyway by those from the legal team - that is nice as well.
While the experts are listening one follow up question: Is there a state of the art golang package / spec file, that can be recommended as template for a new package, that will be generated from sources with "vendored" packages and should produce a package including a binary, some config files, systemd unit files, a separate python script and possibly some documentation? Or is the template from https://en.opensuse.org/openSUSE:Packaging_Go the best approach? All the best, cunix -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
On 04/05/2018 12:14 AM, cunix wrote:
Cunix:
Hello!
[...]
By replying to myself I want to thank you, Aleksa and Jordi, in one mail for your prompt and comprehensive answers to all of my questions.
While I've looked at https://en.opensuse.org/openSUSE:Packaging_Go I wasn't sure if it is exactly up to date and some used terms, e. g. "library" in the context of go packaging, are now better understood with your answers.
From the point of a packager it is nice to hear, that time can be spend immediately on the target package instead of having to create a lot of needed other packages before. Your answers regarding licenses seem to differ slightly, but as I understand, this will be decided (in case of a factory submit request) by legal review. No matter which way is chosen in the beginning, it will be corrected anyway by those from the legal team - that is nice as well.
While the experts are listening one follow up question:
Is there a state of the art golang package / spec file, that can be recommended as template for a new package, that will be generated from sources with "vendored" packages and should produce a package including a binary, some config files, systemd unit files, a separate python script and possibly some documentation?
Or is the template from https://en.opensuse.org/openSUSE:Packaging_Go the best approach?
These are all good examples and the latest packages our team has worked on: https://build.opensuse.org/package/show/devel:CaaSP:Head:ControllerNode/cri-... https://build.opensuse.org/package/show/devel:CaaSP:Head:ControllerNode/podm... https://build.opensuse.org/package/show/devel:CaaSP:Head:ControllerNode/etcd https://build.opensuse.org/package/show/devel:CaaSP:Head:ControllerNode/kube... -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
Jordi Massaguer Pla:
[...]
These are all good examples and the latest packages our team has worked on:
https://build.opensuse.org/package/show/devel:CaaSP:Head:ControllerNode/cri-... https://build.opensuse.org/package/show/devel:CaaSP:Head:ControllerNode/podm... https://build.opensuse.org/package/show/devel:CaaSP:Head:ControllerNode/etcd https://build.opensuse.org/package/show/devel:CaaSP:Head:ControllerNode/kube...
These seem to cover a lot and are likely to be very helpful for my use case. Thank you very much! All the best, cunix -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
cunix:
Hello! [...] [1] https://github.com/jedisct1/dnscrypt-proxy
Want to mention, as a follow up, that this is building since a few weeks in my home repo [2]. It is probably not ready for prime time, but working for me. What might be of interest for this group, using an ugly script, the created packages include a copy of the licences of all vendored software. Regarding the described legal issues this might push the distributor further to the save side. All the best, cunix [2] https://build.opensuse.org/package/show/home:cunix:go/dnscrypt-proxy2 -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
participants (3)
-
Aleksa Sarai
-
cunix
-
Jordi Massaguer Pla