[pkg-go] Minutes for the DebConf17 BoF

[Martín Ferrari]

On 20/08/17 19:21, Michael Stapelberg wrote:

>> Gccgo has many quirks. One is that it does not use the vendor directory
>> (I need to check if this is true with the latest version), so you might
>> need to copy vendor into the builddirectory.
> 
> …hopefully only temporarily, though, right? Ideally, we wouldn’t have
> any vendored source in our packages.

Gah! Another thing I forgot to talk about! go packaging is hard.. :)

Yes, most of the time I kill all vendoring, but there have been some
exceptions: 1) small, useless libraries that I see no point in packaging
separately; and 2) self-contained parts of a library, that avoid
dragging 100s of dependencies.

The latter happened to me recently with prometheus: I had removed the
vendoring of the consul API, but when I tried to backport that, I
realised I'd need to backport consul, docker, and way too many dependencies.

Sadly, even if the client API is in a different package, the source
packages have long dependency chains. I am starting to think that for
some of these packages, having a separate source package with client
APIs would make sense.


>> BUILDFLAGS := -ldflags \
>>   " -X $(METAPKG)/version.Version=$(VERSION)\
>>     -X $(METAPKG)/version.Revision=$(REV)\
>>     -X $(METAPKG)/version.Branch=$(BRANCH)\
>>     -X $(METAPKG)/version.BuildUser=$(USER)\
>>     -X $(METAPKG)/version.BuildDate=$(BUILD_DATE)\
>>     -X $(METAPKG)/version.GoVersion=$(GO_VERSION)"
> 
> What does METAPKG resolve to? We should consider centralizing these
> definitions somewhere.

Ah, this is prometheus-specific. All the meta info is stored in the
prometheus/common namespace, so I defined that earlier in the rules file.


-- 
Martín Ferrari (Tincho)