Re: Proposed Fedora packaging guideline: More Go packaging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Dec 17, 2017 at 2:11 AM,  <nicolas.mailhot@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux