----- Original Message -----
From: "nicolas mailhot"
Cc: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>, "Discussion of RPM packaging
standards and practices for Fedora" <packaging(a)lists.fedoraproject.org>
Sent: Monday, February 5, 2018 12:16:14 PM
Subject: [Fedora-packaging] Re: <DKIM> Re: Proposed Fedora packaging guideline:
More Go packaging
----- Mail original -----
De: "Jakub Cajka"
> I think one of the main responsibilities of Fedora packager is to work with
> upstreams, help them
> mature and generally improve their projects.
Sure but expecting everything to be perfect and consistent before shipping
anything just DOES NOT WORK. Reality is not black and white, it's messy with
shades of gray
Even the C/C++ guys do not manage to ship a compat-free package ecosystem,
and their projects had a few more decades than Go projects to mature, and
rpm was pretty much built around C/C++ expectations.
Compat packages are a fact of life in any large software ecosystem, where you
can't achieve perfect cohesion. Go is getting *very* large. It needs compat
packages. That does not mean there will be hundreds of them because,
creating packages is *work*, that does not need they will need maintaining
for years, because the aim of each compat package is to get obsoleted as
fast as possible, but there will always be some of them at any given time.
We are not building a cathedral. Bazaars are messy when full of life.
> Do you have any evidence supporting this claim? From my point of view Jan
> and other packages has
> been spending lot of time on on boarding packagers and working on tooling.
No one (and certainly not me) is accusing you or Jan not to spend a crazy
amount of time and energy trying to make things work. But you did not
achieve a satisfactory Go state in Fedora, read again what Owen wrote, I
didn't put any word in his mouth, even though I could have written pretty
much the same message a few months ago.
Again, no one (and certainly not me) disputes your level of dedication to the
"cause". You just made some choices in the past (trying to avoid working
within rpm via godep, refusing to include different states of the same Go
code in the distro when major Go apps *disagree* on the correct state to
include) that didn't work out in practice, with the hindsight of several
years of Fedora Go packaging and the Go package state achieved in Fedora
after those years.
It's time to adjust those choices a bit.
> From my perspective distribution will end up with crazy amount of
> bitrotting, backport, constant
> attention requiring package crud..., IMHO basically same as now, apart of
> it we will have few 1000s
> of Go based packages with compat names nobody cares about, instead of
> current 500 or so packages.
Fedora has lots of Go packages no one cares about because they do not permit
building the apps people *do* care about.
Building the apps people care about requires a more aggressive update policy,
and accepting people will work in parallel on apps, that demand different
code states, of common dependencies. And there are not so many of those, I
count 18 of them in our repo out of 476 Go packages, even though the work is
not completely finished, and finalizing the build of complex tip apps is
almost certain to increase the proportion a little. That's awfully *good*
and *nice* given the "no Go API compatibility" scarecrows people like to
You won't *ever* attract a large pool of packagers, to work on a package
baseline, that will eventually in some years permit building apps, but never
this year, because upstream state is not conflict and compat-free yet.
packaging mailing list -- packaging(a)lists.fedoraproject.org
To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
Our as Fedora or yours company/org? I believe that your contribution of those in to Fedora
will be much appreciated.
But IMHO even your changes will not change this, if you don't have few dedicated
packager around to do all the bidding.