On 04/29/2015 06:38 PM, Adam Miller wrote:
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 #38.
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
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 :)