[pkg-go] Build failures in arch:all packages (Was Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el)
Martín Ferrari
tincho at tincho.org
Thu Mar 31 00:59:14 UTC 2016
On 28/03/16 19:16, Martín Ferrari wrote:
> Hi all,
>
> I filed today the bug referenced below, and got me thinking about the
> wider issue of having hundreds of arch:all packages which might not be
> working at all on certain architectures, waiting for some arch:any
> package to pull them as dependency to finally blow up.
So I have been talking around with people about this issue, in
particular with tianon on IRC.
My first thought was to propose automatic rebuilding of packages when
their dependencies change (directly or even transitively). I would add
to that making automatinc binNMUs of these, plus rebuilding arch:all
packages in every arch, but that's possibly a pipe dream :)
That's proposing a pretty big change to the autobuilders, which would
meet quite a bit of resistance (although I think it should be explored
too). So another approach was mentioned to me: autopkgtest.
I know about that project for a while, as I saw pkg-perl people
implement it. But I did not follow any of the details. Today I took a
deeper look, and it seems that we would benefit tremendously from that!
The idea of autopkgtest is to mark packages as having an automated
post-build test suite, so the ci.debian.net project would pick them
automatically (and also for our own testing).
These tests would trigger each time the package or its dependencies are
updated, and they consist of installing the package and its
dependencies, and running a series of scripts to verify proper
behaviour, run unit tests, etc. All executed using the installed package
instead of a source tree.
So a simple and effective way to have all our packages be continually
tested would be to add a test description file that runs
"GOPATH=/usr/share/gocode/ go test $GO_PKG".
But even better than that would be to follow what other teams have done
(ruby, perl, python) and add generic tests for the go libraries,
directly into the autopkgtest insfrastructure.
This is a description of how to create tests:
https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
Here is the description of how the pkg-perl did their integration,
making most of the testing automatic:
http://pkg-perl.alioth.debian.org/autopkgtest.html
I think this would be a great asset for the team. What do you people think?
--
Martín Ferrari (Tincho)
More information about the Pkg-go-maintainers
mailing list