Dne 27.7.2015 v 12:00 Jan Chaloupka napsal(a):
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.
And how often this happens?
> 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.
Yes, and I say that about them. You can ask Perl maintainers at minimum.
The worst thing is that you already take them as an excuse to not do the
right thing :/
go-srpm-macros provides only macros.go-srpm file which takes about 1.1
KB of your memory.
That is just one metrics you deliberately chose, ignoring the others.
Vít