On 2018-04-04, cunix wrote:

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/

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