#734 More Go packaging
Closed: nothingtodo 7 months ago by tibbs. Opened 4 years ago by nim.

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.

Since the oldest change to the Go guidelines in git is newer than this ticket, I'm just going to close this out. I'm sure that changes are needed to the existing guidelines, but those should happen in a separate ticket or PR.

Metadata Update from @tibbs:
- Issue close_status updated to: nothingtodo
- Issue status updated to: Closed (was: Open)

7 months ago

Login to comment on this ticket.

Metadata