[opensuse-go] State of go
Hello all, as i have done preliminary work on packaging letsencrypt tool called acmetool, i would like to ask what would be best course of action to push packages to devel:language:go and after that into factory as is. Everything boils down to one question: Should i vendor in everything so i can "just" build binary or repackage binary (was doing that too for my own purpose until i built all dependencies by hand :) )? acmetool: https://github.com/hlandau/acme from source acmetool: https://build.opensuse.org/project/show/home:bmanojlovic:golang binary package acmetool: https://build.opensuse.org/package/show/home:bmanojlovic:webmail/acmetool Boris P.S. packages are roughly built for this to work, so it will take time to SR then into devel:language:go -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
On 2018-02-09, Boris Manojlovic
as i have done preliminary work on packaging letsencrypt tool called acmetool, i would like to ask what would be best course of action to push packages to devel:language:go and after that into factory as is. Everything boils down to one question: Should i vendor in everything so i can "just" build binary or repackage binary (was doing that too for my own purpose until i built all dependencies by hand :) )?
The key thing to note is that we do not package Go libraries anymore -- please vendor all your dependencies (upstream should already be doing this) and then just publish a package for the *binary*. There are plenty of examples in devel:languages:go and Virtualization:containers of how you can package a Go binary using golang-packaging -- just make sure that you BuildRequires: golang(API) = VERSION. However, you really shouldn't submit a binary to devel:languages:go just because it's written in Go (there are some, but IMO those are mostly mistakes and shouldn't be copied). Since it's a LetsEncrypt tool you might want to put somewhere in the server:* namespace. golang-packaging is already in openSUSE, so you can use it outside of devel:languages:go. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
Looking at issue regarding "vendorization" of acmetool, it was already asked
on issue tracker https://github.com/hlandau/acme/issues/132 and as can be
seen official comment regarding it is that it will never be done as commit
into repository, so my only option is to provide binary myself, but doing
that in my view is not something that is easily repeatable - what i wanted
to do exactly with using specific packages, again if that is policy i will
try to do that instead even if i do not like it too much.
i am already using golang-packaging if that was not already obvious,
and it really helps a lot!
Regarding d:l:go ok no problem, that is exactly why i asked here
before doing SR :)
On Sat, Feb 10, 2018 at 9:08 AM, Aleksa Sarai
On 2018-02-09, Boris Manojlovic
wrote: as i have done preliminary work on packaging letsencrypt tool called acmetool, i would like to ask what would be best course of action to push packages to devel:language:go and after that into factory as is. Everything boils down to one question: Should i vendor in everything so i can "just" build binary or repackage binary (was doing that too for my own purpose until i built all dependencies by hand :) )?
The key thing to note is that we do not package Go libraries anymore -- please vendor all your dependencies (upstream should already be doing this) and then just publish a package for the *binary*.
There are plenty of examples in devel:languages:go and Virtualization:containers of how you can package a Go binary using golang-packaging -- just make sure that you BuildRequires: golang(API) = VERSION.
However, you really shouldn't submit a binary to devel:languages:go just because it's written in Go (there are some, but IMO those are mostly mistakes and shouldn't be copied). Since it's a LetsEncrypt tool you might want to put somewhere in the server:* namespace. golang-packaging is already in openSUSE, so you can use it outside of devel:languages:go.
-- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-go+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-go+owner@opensuse.org
On 2018-02-12, Boris Manojlovic
Looking at issue regarding "vendorization" of acmetool, it was already asked on issue tracker https://github.com/hlandau/acme/issues/132 and as can be seen official comment regarding it is that it will never be done as commit into repository, so my only option is to provide binary myself, but doing that in my view is not something that is easily repeatable - what i wanted to do exactly with using specific packages, again if that is policy i will try to do that instead even if i do not like it too much.
Alright, I'm a little confused about the conclusion of that issue. As you've probably noticed, openSUSE doesn't use Debian's Go packaging system (for the primary reason of "we tried it with Ruby and it turned out to be a nightmare"). So from that perspective, the issue you linked shouldn't affect packaging in openSUSE. Maybe I missed something, but I didn't see a comment saying "we will never commit vendor/ into our tree". At the same time, it does look like that repo doesn't actually vendor their sources (and it does contain third-party repositories like "github.com/hlandau/goutils" as well as some packages from "golang.org/x/..."). Builds in OBS don't have access to the internet, and in addition builds in OBS should be reproducible. So from my perspective, the current status of the upstream project is that they should vendor their packages (using the standard Go 1.5+ vendoring style). (As an aside, I have been planning some work on improving the state of packaging vendor/-style packages in different languages. So even if they choose to just provide a "vendor.conf" or similar manifest, I can help you with automated pulling and packaging of those components.) -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
participants (2)
-
Aleksa Sarai
-
Boris Manojlovic