https://bugzilla.redhat.com/show_bug.cgi?id=1451124
--- Comment #1 from Jan Chaloupka <jchal...@redhat.com> ---
Given the cni is a go project:
- if it is possible we should package entire devel subpackage (including its
dependencies)
- if it is possible the project should be built from bundled dependencies
- if possible, project tests should be run
- if possible, the project should be built over all available architectures
- if possible, the spec file header should contain macros that reference
project location
I have generated the new spec file via gofed and incorporated part of your spec
file into it [1].
Currently (referring to your spec file):
- project is built from bundled dependencies (I would recommended that only in
cases when there is no other way)
- devel subpackage is missing build-time and run-time dependencies
- tests are not run (given some of the tests need to be run as a root and
others need additional configuration, they do not have to be run)
- no unit-test subpackage: even if the tests are not run, the _test.go files
can by analysed by tooling and/or run in specialized CI so it is always useful
to package the unit-test package as well
- though there is no strict structure of the spec file header, I recommend to
define provider_prefix, import_path and commit macros. I got a tooling that
periodically scans all go projects in Fedora rawhide and collects various
data/metadata from the go rpms. Plus, if the macros are set, you can use gofed
tooling to update the spec file.
- exclusive archs are set to %{go_arches}: out aim is to generate spec files
that can be built over various architectures and OSes. Unfortunately, the
%{go_arches} macro is not present on CentOS or RHEL so the current spec file
with work on Fedora only. Check [1] for the general ExclusiveArch value. The
same holds for golang BuildRequires.
- in Fedora %gobuild macro is defined that encompasses the BUILD_ID for you so
there is no need to do that manually. However, the same limitations hold here.
The macro is present on Fedora only so the macro is redefine at spec file
header if not defined, see [1].
- I would not call the ./build script as it usually runs more than is needed
and hides the building itself. As long as the build steps are simple, I would
recommend to put them into the %build section.
- not sure about the name, kubernetes uses kubernetes-cni, which I would see
instead of containernetworking. But, I have no strong preference over the name
so basically any name that is close to cni is acceptable.
The references spec file [1] is an example, not something you need to follow.
Yeah, it is pretty long and there is a lot of constructions that make it hard
to read. But, it has its advantages.
[1] https://github.com/gofed/reviews/pull/5/files
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list -- package-review@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
