Hi, we need to discuss how we can support applications written in Go for stretch.
The most radical approach would be not to ship any Go applications in stretch, only the basic Go language implementations. This is probably not desirable. So we need something to deal with the static linking issue. The current state seems to be that -dev packages do not contain object code. This means that they can be built in any admissible order (as determined by their (versioned) build dependencies), without altering the end result, which simplifies matters somewhat (but see below). One approach would be to ship applications as source code only (just like libraries), and compile them locally upon installation. This is what Emacs and Common Lisp implementations already do. With the growth of Go compilation and link times, this seems less and less attractive, though. The alternative is to rebuild reverse dependencies as needed. I can see two challenges with that. Right now, the Built-Using field only records the source versions of the *direct* dependencies (based on the dh_golang manual page and a few examples I looked at). If a critical update happens farther down the dependency chain, a tool based on Built-Using will not mark the top-level package as a rebuild candidate. When performing the rebuild, it is possible to compensate for that by rebuilding everything that has an outdated Go source package in its Build-Using field, iteratively, until we reach a fixpoint. But this does not currently work because the -dev packages do not contain Built-Using information. But this requires that the source package version changes as a result of the rebuild. I'm not sure if this is what happens. Ideally, we want to do this with binNMUs, not sourceful uploads. We may also need some build ordering optimization to avoid redundant rebuilds. This means that the fact that the -dev packages contain no object files is of little practical consequence: The optimization would have to order the builds in the same way as if they did contain object code. But maybe the optimization is not needed. It does not seem possible to determine rebuild candidates based on Built-Using alone, building the transitive closure after the fact. It may have changed between the original application build and subsequent library builds. Unrelated to all that, we cannot currently perform binNMUs in the security archive because it does not contain a completely copy of the main archive. I'm not sure if there are good approaches to deal with this yet. Comments? Florian _______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
