On Sun, Aug 20, 2017 at 7:18 PM, Martín Ferrari <tin...@tincho.org> wrote:
> On 20/08/17 17:35, Martín Ferrari wrote:
>> So, my turn to describe workflows.
> Some things I forgot in my previous email:
> * I am not married to the idea of dch + debcommit, specially when I have
> merge conflicts. I understand the merits of git commit + gbp dch.
> * The export=WC option in gbp.conf is to make sure my uncommitted
> changes are taken into account when building, which allows me to
> experiment and test before committing.
> Some notes not about workflow, but about packaging strategies:
> 1. debian/control
> I wrap and sort all multi-entry fields, with a trailing comma at every
> line (to minimise diffs). I always did this by hand (or with my
> pkg-go-common-fixes script), but a friend just recommended the
> wrap-and-sort script from devscripts, and I think we should all use that
> with the same options.
> Even if this does not match what I am currently doing (indent after
> colon), I think it makes more sense:
> $ wrap-and-sort -st
> Add myself as Uploader for any package where I do some non-trivial
> amount of work. Although I think this usage of Uploaders is being
> challenged project-wise.

Strong +1. Let’s auto-format all things we can reasonably auto-format.
debian/control files are a good candidate for that :).

> Add Testsuite: autopkgtest-pkg-go to every package.
> 2. debian/rules
> Keep it as minimal as possible.
> To add extra needed files (for tests and the such) use
> To avoid compilation and testing of some packages use DH_GOLANG_EXCLUDES.
> If I need to do something in the build directory, pass --builddirectory
> to dh, so it is a known location (as opposed to getting the weird path
> from debhelper)
> 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.

> For detecting gccgo, and doing special things:
> GCCGO      := $(strip $(shell go version | grep gccgo))
> ifneq ($(GCCGO),)
> ..
> endif
> Many programs include versions, build info, date, etc, through linker
> variables. To make it consistent and reproducible I use this:
> DEBVERS    ?= $(shell dpkg-parsechangelog -SVersion)
> VERSION    ?= $(shell echo '$(DEBVERS)' | sed 's/^[[:digit:]]*://;
> s/[-].*//')
> DEBDATE    ?= $(shell dpkg-parsechangelog -SDate)
> REV        := $(DEBVERS)
> BRANCH     := debian/sid
> USER       := pkg-go-maintainers@lists.alioth.debian.org
> HOSTNAME   := debian
> BUILD_DATE := $(shell date --utc --date='$(DEBDATE)' +%Y%m%d-%H:%M:%S)
> GO_VERSION := $(shell go version | sed 's/go version \(\S*\).*/\1/')
> 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.

Best regards,

Pkg-go-maintainers mailing list

Reply via email to