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