Go rpm macroses in rhel8 and epel

[Denis Fateyev]

Hello all,

Originally posted to go-sig@, but haven't got any answer, maybe here will
be better luck.

I have recently tried to rebuild some Golang modules packages against
epel8, and found out that there were build issues at "%goprep".

Could anybody provide some more info: are Go rpm macroses not fully
backported to RHEL8 currently? Any kind of blockers, perhaps?

[Alejandro Saez Morollon]

Hi Denis.

Which package gave you issues? Just to try to build it by myself.

Thanks!

On Wed, Aug 12, 2020 at 10:17 PM Denis Fateyev  wrote:
> Hello all,
>
> Originally posted to go-sig@, but haven't got any answer, maybe here will be better luck.
>
> I have recently tried to rebuild some Golang modules packages against epel8, and found out that there were build issues at "%goprep".
>
> Could anybody provide some more info: are Go rpm macroses not fully backported to RHEL8 currently? Any kind of blockers, perhaps?
>
> --
> wbr, Denis.
> _______________________________________________
> golang mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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]

[Denis Fateyev]

Hello Alejandro,

Thanks for the answer.
There are plenty of them that are failing. From the latest ones, you could
check e.g. "golang-github-termie-shutil", there is a scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=49656829

On Mon, Aug 17, 2020 at 5:27 PM Alejandro Saez Morollon 
wrote:
> Hi Denis.
>
> Which package gave you issues? Just to try to build it by myself.
>
> Thanks!
>
> On Wed, Aug 12, 2020 at 10:17 PM Denis Fateyev  wrote:
> > Hello all,
> >
> > Originally posted to go-sig@, but haven't got any answer, maybe here
>
> will be better luck.
> > I have recently tried to rebuild some Golang modules packages against
>
> epel8, and found out that there were build issues at "%goprep".
> > Could anybody provide some more info: are Go rpm macroses not fully
>
> backported to RHEL8 currently? Any kind of blockers, perhaps?
> > --
> > wbr, Denis.
> > _______________________________________________
> > golang mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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]
> _______________________________________________
> golang mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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]

Le 2020-08-20 22:05, Denis Fateyev a écrit :
> > > Could anybody provide some more info: are Go rpm macroses not
> >
> > fully backported to RHEL8 currently? Any kind of blockers, perhaps?

Unfortunately, while the Go-specific logic of the macros is quite 
release-agnostic, they depend on some common code in redhat-rpm-config 
that did not make it to EL8. The way @rh freezes common tooling at the 
start of an EL release inherently conflicts with languages like Go which 
are still fast evolving and requiring changes not fossilized a decade 
ago.

And it would be quite hard to both froze initial EL implementation in 
stone and provide parallel updates (modularity & containers only work 
for leaf features not core shared low level code)

Regards,

[Nicolas Mailhot]

Le 2020-09-01 15:17, Nicolas Mailhot a écrit :
> Le 2020-08-20 22:05, Denis Fateyev a écrit :
> > > > Could anybody provide some more info: are Go rpm macroses not
> > >
> > > fully backported to RHEL8 currently? Any kind of blockers, perhaps?
>
> Unfortunately, while the Go-specific logic of the macros is quite
> release-agnostic, they depend on some common code in redhat-rpm-config
> that did not make it to EL8. The way @rh freezes common tooling at the
> start of an EL release inherently conflicts with languages like Go
> which are still fast evolving and requiring changes not fossilized a
> decade ago.
>
> And it would be quite hard to both froze initial EL implementation in
> stone and provide parallel updates (modularity & containers only work
> for leaf features not core shared low level code)

Though if anyone is willing to go down this particular rabbit hole, I 
will provide support and answer questions. From very very very far away 
:)

[Denis Fateyev]

Hello Nicolas,

Also, we have recently discussed this matter with Robert-André Mauchin
(@eclipseo).

To make a long story short, for packaging binaries we basically have two
options for EPEL8:

1) Using vendored dependencies aka using Go modules functionality, and
providing modules archive as a SourceXX.
It works, but evidently it produces bulky SRPMS, and requires some efforts
to maintain a single spec across various branches as well;

2) Using side-tags (the approach I'm not really familiar with, but it looks
promising).
Would be glad if someone could provide a working snippet set which could be
used for packaging Go binary packages.

On Tue, Sep 1, 2020 at 7:17 PM Nicolas Mailhot 
wrote:
> Le 2020-08-20 22:05, Denis Fateyev a écrit :
> > > > Could anybody provide some more info: are Go rpm macroses not
> > >
> > > fully backported to RHEL8 currently? Any kind of blockers, perhaps?
>
> Unfortunately, while the Go-specific logic of the macros is quite
> release-agnostic, they depend on some common code in redhat-rpm-config
> that did not make it to EL8. The way @rh freezes common tooling at the
> start of an EL release inherently conflicts with languages like Go which
> are still fast evolving and requiring changes not fossilized a decade
> ago.
>
> And it would be quite hard to both froze initial EL implementation in
> stone and provide parallel updates (modularity & containers only work
> for leaf features not core shared low level code)
> Regards,
>
> Nicolas Mailhot