On 04/29/2015 06:38 PM, Adam Miller
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?
Yes. There is still a lot of problems to be solved. Look at comment
As long as there are no releases which does not break back
compatibility, it is hard to make rules on packaging dependencies.
We can, of course, describe a perfect situation and then write down
a list of exceptions and how to deal with it.
Also, since Go is statically compiled by default is this something
we need to get an exception from FESCo similar to OCaml?
Another topic of note is bundled libraries. The upstream Go
community seems pretty content with just bundling in their
dependencies since it's all statically linked anyways (yes, you can
dynamically link with gcc-go but I've yet to find a single project out
in community space doing that).
IIRC it was etcd or kubernetes who started this because of rapidly
changing imported packages and their API breaking.
For some popular Go projects the dependency list is over 100
deps and are managed with something similar to Godep, I'm not
sure how realistic it is for packagers to be expected to maintain that
At the moment I am maintaining almost all of them. As almost all of
the builds are source codes only their maintenance is generic. I
have already written a tool for it . It allows to update spec
file, build package, update it, override it and so on for each
branch simultaneously. Some analysis of projects (API diff, check of
Godeps.json file, etc.) is available as well.
This also begs the question that if we do require a
packager to maintain them, what happens if another project requires a
different version of that dep? (This is similar in nature to what I
like to call "ruby bundler hell").
Yeap. Already happening. Until now I have not had to package
different versions/commits of the same project/source code. I have
always managed to find a commit of source codes that is working for
all projects. But it is a different commit than upstream/Godeps.json
uses. Another way is to use bundled deps (ugly). Or package more
versions of the source code (hope this will not happen).
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
At the moment you can generate a graph of dependencies between
golang packages using 'gofed scandeps' (for all package or specific
package). Then by look find which package depends on
which and choose ones for rebuilding. As gofed's documentation is
poor there is still a lot of undescribed features and commands. But
it should give you basic notion what the tool does.
I wanted to at least get this conversation going because it
appears there's already a number of Go packages in Fedora at this time
without any approved standard and as the language continues to gain
popularity I can only assume that number will increase.
Almost all spec files are generated using gofed. From time to time
kubernetes introduces new packages or existing packages need to be
updated. In this case I am polishing their spec files and keeping
them in shape. But as I am dealing with new problems (like moving
project from one repository to another, change of import path
prefix, etc.) final form of a spec file is changing.
At the time of this writing, on my laptop running Rawhide:
$ dnf search golang | wc -l
Some builds belongs to the same package so the number is not so
high. But still :)
 - https://fedoraproject.org/wiki/PackagingDrafts/Go
 - https://fedoraproject.org/wiki/Packaging:Guidelines#Programs_which_don.27t_need_to_notify_FESCo
 - https://github.com/openshift/origin/blob/master/Godeps/Godeps.json
 - https://github.com/tools/godep
packaging mailing list