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(a)opensuse.org
To contact the owner, e-mail: opensuse-go+owner(a)opensuse.org
Hello @hillwood,
First off, I owe you an apology. You submitted several SRs to add new
packages to devel:languages:go in order to maintain Deepin. I read
through the SRs when you first posted them and wasn't sure how to
respond, so I didn't say anything. And then they just sat for longer and
longer without any more action taken. I shouldn't have done that. Here
is the email I should have sent you 5 months ago.
The main problem that I had when looking at the SRs is that they are
packaged according to the old packaging guidelines (each Go project has
its own package as a "library"). This model was based on Ruby, but we
very quickly discovered that it doesn't work very well (it causes many
breakages on the package level and makes dealing with upstreams harder).
The new standard for Go packaging in openSUSE is to use vendoring (where
all of the dependencies are placed in a top-level vendor/ directory).
Most upstream Go projects follow this style. As a result we no longer
package library packages for Go. (This obviously brings some
maintenance burden, but given recent developments in the Go community it
seems quite likely that this is going to be very close to how Go's
community envisions distribution-style packaging).
This means that if you want to submit the Deepin packages to the
devel:languages:go project you would need to repackage them in the new
style. However, you might not want to include your packages in
devel:languages:go at all! The only packages that /should/ be in
devel:languages:go are development tools for Go, and other packages
should go into their appropriate package (in the case of Deepin, I
imagine that it would be X11:Deepin -- where the packages already live).
Unfortunately, currently devel:languages:go is not really where it
should be (quite a few packages don't match the guidelines I just
described). This is mostly caused due to a lack of time, and the fact
that we would need to remove those now-incorrectly-packaged packages
from TW and Leap.
I was worried it would be a bit hypocritical to ask you to change your
packages even though our own packages are not really correct either.
Again, I'm sorry that it took so long to give you a response to your
SRs. In retrospect, it's pretty obvious that not responding made the
situation much worse than just explaining the situation from the outset.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
