Moritz Mühlenhoff: > Niels Thykier wrote: >> If the issues and concerns from you or your team are not up to date, >> then please follow up to this email (keeping debian-release@l.d.o and >> debian-ports@l.d.o in CC to ensure both parties are notified). > > Two issues that we discussed at the recent Security Team sprint wrt > problems affecting buster: > > [...] > > (2) Not an architectual issue, but a cross-arch problem: Buster is > reaching a critical mass of applications written in Go and our tooling > for security updates is absolutely not in a position to deal with it's > approach to link everything statically: > > dak on ftpmaster and security-master don't share tarballs, IOW the > first time an application is updated in foo-security it's needs an > upload including the orig tarball. That's somewhat manageable for > standard security updates, but if we'd need to recompile all reverse > deps with individual source uploads (which would be dozens to hundreds > of packages if it's e.g. in Golang itself), it ends up being total > madness. > > To be able to support Go-based applications in buster-security we > need tooling which > - detects which packages need a rebuild if a given Go package has been > fixed. > - handles the actual rebuilds and sharing tarballs between security-master > and ftp-master is an automated manner > > Cheers, > Moritz >
Hi Moritz, Thanks for highlighting this issue. Do you have any idea on whether anyone is working on this tooling at the moment (e.g. the tarball sharing between security- and ftp-master)? What do you envision as the contingency plan if the tooling is not in place for buster? Thanks, ~Niels