On Mon, Sep 16, 2019 at 8:54 PM Ryan O'Hara <rohara@xxxxxxxxxx> wrote: > > > > On Mon, Sep 16, 2019 at 1:44 PM Gergely Polonkai <gergely@xxxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx >>> To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx >>> 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/packaging@xxxxxxxxxxxxxxxxxxxxxxx >> >> _______________________________________________ >> packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx >> 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/packaging@xxxxxxxxxxxxxxxxxxxxxxx > > _______________________________________________ > packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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/packaging@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
