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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
