Packaging Go application from tarball

[Ryan O'Hara]

I'd like to package a Go application [1] that provides a tarball for each
stable release. That's great, but it seems that I have two options:

1. Use the tarball as a source in the spec file, the proceed as usual. The
Makefile included with this tarball will handle all the Go dependencies.

2. Treat this as a Go application, avoid the tarball and have the spec file
define all the BuildRequires.

Thoughts? I've been packaging for ages but this will be my first Golang
package. One way seems easier but might not be the best way. Cheers.

Ryan

[1] https://github.com/haproxytech/dataplaneapi

[Gergely Polonkai]

Without any packaging experience, the tar.gz file is not the source, it is
a compiled version of the software. So iʼd say you should go the hard route
and do the compilation in RPM time.

However, as far as my Golang-fu goes, you will have a bunch of build
dependencies, but probably zero runtime deps (which is great in one way,
but i personally find a semi-bad idea).

Best,
Gergely

On Mon, 16 Sep 2019, 18:18 Ryan O'Hara, <rohara(a)redhat.com&gt; wrote:

>  I'd like to package a Go application [1] that provides a tarball
> for each
>  stable release. That's great, but it seems that I have two options:
>
>  1. Use the tarball as a source in the spec file, the proceed as usual. The
>  Makefile included with this tarball will handle all the Go dependencies.
>
>  2. Treat this as a Go application, avoid the tarball and have the spec
>  file define all the BuildRequires.
>
>  Thoughts? I've been packaging for ages but this will be my first Golang
>  package. One way seems easier but might not be the best way. Cheers.
>
>  Ryan
>
>  [1] https://github.com/haproxytech/dataplaneapi
>
>
>
>  _______________________________________________
>  packaging mailing list -- packaging(a)lists.fedoraproject.org
>  To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>

[Ryan O'Hara]

On Mon, Sep 16, 2019 at 1:44 PM Gergely Polonkai <gergely(a)polonkai.eu&gt;
wrote:

>  Without any packaging experience, the tar.gz file is not the source,
> it is
>  a compiled version of the software. So iʼd say you should go the hard route
>  and do the compilation in RPM time.
>  
It is. The tar.gz contains the source, a Makefile that pulls the
dependencies and spits out a binary. Pretty much the equivalent of a C
program that is released as a tarball with a Makefile. I understand that
some (most) C applications also have a configure step, but haproxy never
has and I'm fine with that -- you just prep and build.


>  However, as far as my Golang-fu goes, you will have a bunch of build
>  dependencies, but probably zero runtime deps (which is great in one way,
>  but i personally find a semi-bad idea).
>  
Right. If I treated this as a normal golang application and ignored the
tarball release, I would have to define the dependencies as BuildRequires.
Definitely possible, but since the released tarball does that for me, why
not take advantage of it?

Appreciate the feedback.

Ryan



>  Best,
>  Gergely
>
>  On Mon, 16 Sep 2019, 18:18 Ryan O'Hara, <rohara(a)redhat.com&gt; wrote:
>
> > I'd like to package a Go application [1] that provides a tarball for each
> > stable release. That's great, but it seems that I have two options:
> >
> > 1. Use the tarball as a source in the spec file, the proceed as usual.
> > The Makefile included with this tarball will handle all the Go dependencies.
> >
> > 2. Treat this as a Go application, avoid the tarball and have the spec
> > file define all the BuildRequires.
> >
> > Thoughts? I've been packaging for ages but this will be my first Golang
> > package. One way seems easier but might not be the best way. Cheers.
> >
> > Ryan
> >
> > [1] https://github.com/haproxytech/dataplaneapi
> >
> >
> >
> > _______________________________________________
> > packaging mailing list -- packaging(a)lists.fedoraproject.org
> > To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/[e-mail]...
> >
>  _______________________________________________
>  packaging mailing list -- packaging(a)lists.fedoraproject.org
>  To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>

[Fabio Valentini]

On Mon, Sep 16, 2019 at 8:54 PM Ryan O'Hara <rohara(a)redhat.com&gt; wrote:
>  On Mon, Sep 16, 2019 at 1:44 PM Gergely Polonkai <gergely(a)polonkai.eu&gt; wrote:
> >
> > Without any packaging experience, the tar.gz file is not the source, it is a compiled
> version of the software. So iʼd say you should go the hard route and do the compilation in
> RPM time.
>
>
>  It is. The tar.gz contains the source, a Makefile that pulls the dependencies and spits
> out a binary. Pretty much the equivalent of a C program that is released as a tarball with
> a Makefile. I understand that some (most) C applications also have a configure step, but
> haproxy never has and I'm fine with that -- you just prep and build.
>
> >
> > However, as far as my Golang-fu goes, you will have a bunch of build dependencies,
> but probably zero runtime deps (which is great in one way, but i personally find a
> semi-bad idea).
>
>
>  Right. If I treated this as a normal golang application and ignored the tarball release,
> I would have to define the dependencies as BuildRequires. Definitely possible, but since
> the released tarball does that for me, why not take advantage of it?
>
>  Appreciate the feedback. 
Hi Ryan,

The "best practice" for packaging stuff for fedora (regardless of the
programming language) is to un-bundle third-party sources from
upstream, if possible. That way, improvements to shared dependencies
benefit all dependent packages. This often also benefits the upstream
projects, since the downstream work on bug fixes and ports to newer
versions of their dependencies are often welcome contributions.

However, this also means that you as the packager actually have to
work on this downstream in fedora - porting software to versions of
dependencies that are newer in fedora than in the upstream project,
and submitting bug fixes upstream.

That said, I also maintain a go application for fedora (syncthing),
and switched back to using the bundled dependencies by default some
time ago, since some go packages for its dependencies in fedora were
just too old (and by that I mean, outdated by several years). The
situation has changed for the better now, but I don't have the time to
invest in changing the packaging once again.

The relevant section on bundled dependencies in the Packaging
Guidelines might also be of interest:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling

TL;DR: It depends on the situation whether using bundled dependencies
is appropriate. If un-bundling dependencies requires an unreasonable
amount of busywork, you probably should invest your time into doing
something more fun.

Fabio

> Ryan
>
>
>>
>> Best,
>> Gergely
>>
>> On Mon, 16 Sep 2019, 18:18 Ryan O'Hara, <rohara(a)redhat.com&gt; wrote:
>>>
>>> I'd like to package a Go application [1] that provides a tarball for each
stable release. That's great, but it seems that I have two options:
>>>
>>> 1. Use the tarball as a source in the spec file, the proceed as usual. The
Makefile included with this tarball will handle all the Go dependencies.
>>>
>>> 2. Treat this as a Go application, avoid the tarball and have the spec file
define all the BuildRequires.
>>>
>>> Thoughts? I've been packaging for ages but this will be my first Golang
package. One way seems easier but might not be the best way. Cheers.
>>>
>>> Ryan
>>>
>>> [1] https://github.com/haproxytech/dataplaneapi
>>>
>>>
>>>
>>> _______________________________________________
>>> packaging mailing list -- packaging(a)lists.fedoraproject.org
>>> To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
>>> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...
>>
>> _______________________________________________
>> packaging mailing list -- packaging(a)lists.fedoraproject.org
>> To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...
>
> _______________________________________________
> packaging mailing list -- packaging(a)lists.fedoraproject.org
> To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...

[Nicolas Mailhot]

Hi,

You'll quickly find out that the upstream Makefile does not handle 
anything, it makes a go get call, and go get attempts to download things 
directly from the internet. So, it is completely useless in a Fedora 
context.

So your real alternative is between using the Fedora automation, or 
handcrafting in your spec file all the things needed for building in a 
secure and managed environment, that your upstream made no provision 
for.

Also, I see your upstream has already converted to go modules. This is 
going to be a problem for you because right now Fedora does not handle 
go modules (and upstream gave up on making module mode the default in Go 
1.13 a couple of weeks ago, because module tooling is missing too many 
pieces right now, not just Fedora-side; right now go modules are only 
suitable for direct dev builds on non-production workstation 
environments).

So, basically, to get anything done this year, you need to forget about 
the upstream makefile, and convert the upstream build mode to classical 
GOPATH building mode (unless you want to work with us and Go upstream to 
finish tooling for Go module mode, which would be awfully nice, but most 
people do not want to get involved at this level).

Regards,

-- 
Nicolas Mailhot