Re: Go Packaging Guidelines: What's next?

[Jan Chaloupka <jchaloup@xxxxxxxxxx>]

Hi,

On 04/29/2015 06:38 PM, Adam Miller wrote:

Hello all,
    I've noticed that the Go (golang) Packaging Guidelines Draft[0]
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 something
we need to get an exception from FESCo similar to OCaml[1]?

    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[2] and are managed with something similar to Godep[3], I'm not
sure how realistic it is for packagers to be expected to maintain that
many dependencies.

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 [1]. 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
of?)

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
279

Some builds belongs to the same package so the number is not so high. But still :)

Thank you,
-AdamM

[0] - https://fedoraproject.org/wiki/PackagingDrafts/Go
[1] - https://fedoraproject.org/wiki/Packaging:Guidelines#Programs_which_don.27t_need_to_notify_FESCo
[2] - https://github.com/openshift/origin/blob/master/Godeps/Godeps.json
[3] - https://github.com/tools/godep
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging

[1] https://github.com/ingvagabund/gofed

--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging