[pkg-go] GitLab CI: git-buildpackage and ratt

[Michael Stapelberg]

On Tue, Feb 20, 2018 at 12:06 PM, Martín Ferrari <tincho at tincho.org> wrote:

> Hi,
>
> On 19/02/18 17:13, Michael Stapelberg wrote:
>
> > I see the role of the CI setup as complementary: I expect that people
> > will still build packages locally as they work on the packages. That
> > path will continue to cover the debian/* part of the package. The
> > remainder (fit into the archive) will be covered by the CI. In the worst
> > case, the issue will be caught on the buildds (provided one uses
> > source-only uploads).
>
> OK, good point.
>
> > Regarding the amount of work required to make packages buildable
> > directly with the Go tool, have a look at the examples I listed at the
> > bottom of the document. I don’t expect to spend more than 15 minutes per
> > package, and I can volunteer to do the initial fixes. We need to be on
> > the same page regarding the longer-term strategy, though, otherwise
> > packages will degrade quickly.
> >
> > Does that address your concern?
>
> More or less, there are things that would be very clumsy to do without a
> Makefile. For example, arch-specific build tags, if you don't evaluate
> the complete makefile you won't get those. Granted, if you are only
> using amd64 this would be a non-issue most of the time, although you
>

I’m only aware of one package (jacobsa/crypto) which has a Debian-specific
patch that requires the use of an architecture-specific build tag. My
proposed solution for this is to either specify the architectures (as
opposed to custom pointer size build tags) in the files (they change rarely
enough), or at least add the amd64 architecture.

Are you aware of other packages which use the same technique? If so, it
might be good to write up a little bit of documentation, and perhaps even
make this a feature of dh-golang.


> have things like this that will still require evaluating properly
> debian/rules:
>
> export DH_GOLANG_INSTALL_EXTRA := godoc/static \
>     $(wildcard */*/testdata) $(wildcard */*/*/testdata)
>

This particular example is moot since dh-golang 1.31’s
install-testdata-by-default change :).


>
> Dunno, seems it could work as you propose it, but at the same time I am
> a bit worried that we will need to be careful not to break the system,
> and that it will not be obvious when building locally.
>

I understand your concern. I suggest we try my suggested approach and
re-evaluate at some point down the road (a quarter? a year?) whether
keeping it up is feasible and worthwhile. We can always course-correct,
there’s no lock-in here.

-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20180220/22258026/attachment.html>