On Wed, Apr 29, 2015 at 11:50 AM, Matthew Miller
On Wed, Apr 29, 2015 at 11:38:59AM -0500, Adam Miller wrote:
> Hello all,
> I've noticed that the Go (golang) Packaging Guidelines Draft
> document has been stagnant for a while now and I'm curious what the
> next steps should be? Does this need to go through FESCo?
It shouldn't need to go through FESCo. See
for current state.
> Also, since Go is statically compiled by default is this something
> we need to get an exception from FESCo similar to OCaml?
That's covered in the draft.
Yup, I totally missed that. Apologies.
> If there were to be some sort of approval for these bundled
> libraries, should there be a defined specification of which Go
> dependency managers are supported for sake of security response so
> that we can check for packages that need rebuilding when a
> vulnerability is found? What kind of changes would be necessary for
> build tooling there? (Maybe something in this area I'm not thinking
Now, the bundling issue is an exciting kettle of worms — although the
problem of tons of unpackaged deps is not really that different from
Ruby or even Python or Perl. I think it's fair to say that the _idea_
of the current approach -- first package to require it generally needs
to do the work of getting the dependencies in too -- is geared towards
an eventual benefit to the _next_ packages, which will then find there
deps already nicely available. (Pain now, but globally reduced pain
That's fair I suppose, I just think that the scenario is slightly
different because it's build time vs runtime deps for Go vs
Python/Ruby/Perl. At runtime that giant dep list disappears. Maybe I'm
over thinking this but it does seem different to me. However, I agree
that if we can deal with some pain upfront and have less later then
all the better. Just from a ground zero standpoint it seems like a lot
Thanks for the quick reply, I'll follow along in the fpc trac ticket
from now on.
Fedora Project Leader
packaging mailing list