Packaging golang for secondary architectures, go-srpm-macros

[Dennis Gilmore]

On Monday, July 27, 2015 10:12:03 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. 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.

the very nature of the srpm-macros packages precludes the ability of it being 
added as a BuildRequire the package defines macros that need to be installed 
for srpm creation to set macros and define BuildRequires correctly.  any other 
macro that is defined belongs elsewhere in a packag that is added as a 
BuildRequires.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150902/14ac39c3/attachment.sig>