Packaging golang for secondary architectures, go-srpm-macros

Jan Chaloupka jchaloup at redhat.com
Mon Jul 27 10:00:05 UTC 2015



On 07/27/2015 10:12 AM, Vít Ondruch wrote:
> Dne 26.7.2015 v 14:03 Jan Chaloupka napsal(a):
>> On 07/24/2015 03:36 PM, Vít Ondruch wrote:
>>> Dne 9.7.2015 v 11:18 Jan Chaloupka napsal(a):
>>>> Recommended use in spec file:
>>>> 1) To choose the correct compiler:
>>>> %ifarch %{golang_arches}
>>>> BuildRequires: golang
>>>> %else
>>>> BuildRequires: gcc-go >= %{gccgo_min_vers}
>>>> %endif
>>>>
>>>> 2) To choose the correct command for building and testing:
>>>> %ifarch %{golang_arches}
>>>> %{golang_build} -o bin/binary %{import_path}/binary
>>>> %{golang_test} %{import_path}/binary
>>>> %else
>>>> %{gcc_go_build} -o bin/binary %{import_path}/binary
>>>> %{gcc_go_test} %{import_path}/binary
>>>> %endif
>>>>
>>> Why are you not using the %{?golang_arches} and similar (i.e. with the
>>> "?" at the beginning).
>> Yes, you are right. 0%{?golang_arches} will do better.
>> This was a heads up. Still needs some polishing.
>>
>> %ifarch 0%{?gccgo_arches}
>> BuildRequires:   gcc-go >= %{gccgo_min_vers}
>> %else
>> BuildRequires:   golang
>> %endif
>>
>>> Why the GO compilers does not provide some
>>> virtual provide, which ensures that the compiler is available, without
>>> even checking for architecture? This would avoid the need of requiring
>>> go-srpm-macros by redhat-rpm-config and it could be build require just
>>> by Go packages.
>> It is a question of maintainability. Golang does not support ppc64 at
>> the moment. Supported by gcc-go. In future this can change. Then you
>> would have to update both golang and gcc components. It means report a
>> bug on golang and gcc. For gcc this is not a high priority issue. It
>> would take some time. Plus gcc would have to add ifarch to its spec
>> file as gcc-go and golang has common architectures.
> If you need that change in those packages, it is just one time change
> which will happen only once.

And every time golang or gcc-go changes its list of supported architectures.

> If you were able to convince RPM maintainer
> to introduce this unneeded dependency, I'm pretty sure you can convince
> golang/gcc-go maintainers to introduce the virtual provide where it belongs.
>
>> go-srpm-macros is one point of change. For virtual provides you would
>> need at least two. go-srpm-macros is needed anyway otherwise you
>> duplicate all macros which can get out of sync.
> I don't ming go-srpm-macros. That is perfectly fine, if it is BR of
> package which needs it. But I don't want to have go-srpm-macros
> installed on my system, because I'm quite sure I'm not going to build
> any Go package any time soon and hence this is just cruft.

You can say the same about perl-srpm-macros, ocaml-srpm-macros or other 
*-srpm-macros package redhat-rpm-config has as a runtime dependency.

go-srpm-macros provides only macros.go-srpm file which takes about 1.1 
KB of your memory.

>
> Vít
>


More information about the devel mailing list