Hi Fabio, Robert-André, Thank you for the explanation. It makes sense. Golang has this uniqueness about libs that removes some of the shared objects pros but I see there are other things at play.
Thank you, Carlos. On Thu, Jul 20, 2023 at 1:44 PM <zebo...@gmail.com> wrote: > On 7/20/23 8:20 PM, Carlos Rodriguez Fernandez < > carlosrodrifernan...@gmail.com> wrote: > > Hi all, > > > > I am interested in packaging some golang programs for Fedora (and EPEL), > and I read through > > the guidelines: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/ > > <https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/> > > > > My question is more about the reasoning for the recommended handling of > dependencies. > > > > Other language platforms have shared runtime objects, and devel packages > provide the > > interface to link to them when necessary; however golang compiles it all > statically. It is > > very easy to bring all the dependencies locally for compilation directly > from git repos and > > then nothing is necessary at runtime. > > > > Creating rpm packages for each golang dependency seems counterproductive > as it adds an > > additional burden to maintain without the benefits of shared runtime > objects. > > > > I have the feeling I am missing something. What is the benefit of having > each golang build > > dependency as rpms? > > Is it a requirement for golang programs rpm contributions or it is > optional? (e.g. > > prometheus in EPEL9 does not follow the deps handling guidelines but not > sure if it is a > > tech debt or an option). > > > > > > Thank you, > > Carlos > > > > We need to build into Koji, there is no "local build". As such we have two > options : > - bundle the dependencies in the package > - package all the libraries separately > > The Fedora guidelines is to package library separately, per > https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/ : > > > > All packages whose upstreams allow them to be built against system > libraries must be built against system libraries. > > All packages whose upstreams have no mechanism to build against system > libraries must be contacted publicly about a path to supporting system > libraries. If upstream refuses, this must be recorded in the spec file > using a persistent mechanism to be clarified in the packaging guidelines. > > All packages whose upstreams have no mechanism to build against system > libraries may opt to carry bundled libraries, but if they do, they must > include Provides: bundled() = in their RPM spec file. > > > This policy only applies to Fedora. In EPEL we bundle because we don't > have our macros and the Go ecosystem is not bootstrapped. > > Best regards, > > Robert-André > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
