[Fedora-packaging] Go Packaging Guidelines: What's next?

[Jan Chaloupka]

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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging

[1] https://github.com/ingvagabund/gofed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20150503/17631738/attachment.html>