#734 More Go packaging
Opened a year ago by nim. Modified a year ago

I'd like to propose new Go packaging guidelines. There are no official Go packaging in Fedora right now despite a previous proposal languishing for years.

This proposal depends on the https://pagure.io/packaging-committee/issue/719 draft which contains its non Go-specific parts.

Link to the draft

https://fedoraproject.org/wiki/More_Go_packaging

Link to the technical files

https://bugzilla.redhat.com/show_bug.cgi?id=1523779

Benefits

  • 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.
  • no reliance on external utilities to compute code requirements. No more dependencies that do not match the shipped Go code.
  • no maze of variable indirections. No more packages everyone is afraid of touching.
  • no maze of cargo-culted and bitrotting shell code. No more packages everyone is afraid of touching.
  • compatibility with existing packages (though many are so obsolete they need complete replacement)

I believe that this whole proposal depends on closure/resolution of issue #382 and previous packagers work upon which this proposal builds.

Login to comment on this ticket.

Metadata