On Sun, Dec 17, 2017 at 2:11 AM, <nicolas.mail...@laposte.net> wrote: > Hi, > > 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 > - https://pagure.io/packaging-committee/issue/734 > - go-srpm-macros RFE with the technical files: > https://bugzilla.redhat.com/show_bug.cgi?id=1526721 > > This proposal is integrated with and depends on the > https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation > draft > It builds on the hard work of the Go SIG and reuses the rpm automation of > https://fedoraproject.org/wiki/PackagingDrafts/Go when it exists, and > produces compatible packages. > > 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 notices. > - 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 and overrides. > - 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 the > https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation > draft >
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! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
