English Finnish
If upstream confused itself after multiple forks and renamings, you will need to fix references to past names in the Go source files, unit tests included. Perform this fixing in `+%prep+`.
Source packages (src.rpm)
Golang source packages MUST be named after their main import path. This process is automated by the `+%{goname}+` macro. This macro will remove any capitalization, "go" keywords, and any duplication in the import path.
For example:
the import path `+github.com/kr/pretty+` will become `+golang-github-kr-pretty+`
the import path `+github.com/DATA-DOG/go-txdb+` will become `+golang-github-data-dog-txdb+`
the import path `+github.com/gopherjs/gopherjs+` will become `+golang-github-gopherjs+`
The filename of spec MUST match the name of the package.
If you're not sure what will the name processed by the `+%{goname}+` macro be, simply build the SRPM with:
fedpkg --release f31 srpm
The SRPM filename will be the one to use in your rpmspec and spec filename.
Source packages that provide a well-known application such as `+etcd+` MUST be named after the application. End users do not care about the language their applications are written in. But do not name packages after an obscure utility binary that happens to be built by the package.
Implementation: `+%{gorpmname}+`
`+%gometa+` uses the `+%{gorpmname}+` macro to compute the main `+%{goname}+` from `+%{goipath}+`.
*`+%{gorpmname}+` can produce collisions*
`+%{gorpmname}+` tries to compute human-friendly and rpm-compatible naming from Go import paths. It simplifies them, removing redundancies and common qualifiers. As a result it is possible for two different import paths to produce the same result. In that case, feel free to adjust this result manually to avoid the collision.
Go code packages: `+%{goname}-devel+`
In a source package dedicated to providing Go code
Packages that ship Go code in `+%{goipath}+` should be named `+%{goname}-devel+`. If your source package is already named `+%{goname}+`, that is easily achieved with: