On Sun, Dec 17, 2017 at 2:11 AM, <nicolas.mailhot(a)laposte.net> wrote:
I am proposing for inclusion a set of rpm technical files aimed at automating the
packaging of forge-hosted projects.
- Packaging draft: https://fedoraproject.org/wiki/More_Go_packaging
- go-srpm-macros RFE with the technical files:
This proposal is integrated with and depends on the
It builds on the hard work of the Go SIG and reuses the rpm automation of
when it exists, and produces compatible
What it does:
- drastically shorter spec files, up to 90% in some cases, often removing hundreds of
lines per spec.
- simple, packager-friendly spec syntax
- automated package naming derived from the native identifier (import path). No more
packages names without any relation with current upstream naming.
- working Go autoprovides. No forgotten provides anymore.
- working Go autorequires. No forgotten requires anymore.
- strict automated directory ownership (used by autorequires and autoprovides).
- centralized computation of source URLs (via Forge-hosted projects packaging
automation). No more packages lacking guidelines. No more broken guidelines no one
- easy switch between commits, tags and releases (via Forge-hosted projects packaging
automation). No more packages stuck on commits when upstream starts releasing.
- guidelines-compliant automated snapshot naming, including snapshot timestamps (via
Forge-hosted projects packaging automation). No more packages stuck in 2014.
- guidelines-compliant bootstraping.
- systematic use of the Go switches defined by the Go maintainer. Easy to do changes
followed by a mass rebuild.
- flexibility, do the right thing transparently by default, leave room for special cases
- no bundling (a.k.a. vendoring) due to the pain of packaging one more Go dependency.
- centralized Go macros that can be audited and enhanced over time.
- aggressive leverage of upstream unit tests to detect quickly broken code.
Please consult packaging draft for full information.
The proposal has been tested in Rawhide and EL7 over a set of ~ 140 Go packages. This set
is a mix of current Fedora packages, bumped to a more recent version, rewrites of Fedora
packages, and completely new packages.
I hope posting the second part of the automation will answer some questions people had on
I really do like this. There are only two issues I have with it:
1. This seems to mandate that all packages must be named by their
import path. My golang package (snapd) is not, intentionally so. I
don't want to change this.
2. Mandating a forge is going to be tricky for self-hosted stuff, or
people who release Go code as tarballs (it's rare, but it happens).
How do you deal with that?
真実はいつも一つ！/ Always, there's only one truth!