On Sun, Jul 01, 2018 at 08:54:00AM +0000, Niels Thykier wrote:
> 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)?
I'm not aware of anyone.
> What do you envision as the contingency plan if the tooling is not in
> place for buster?
The canonical solution for unsupportable packages is usually to exclude
them from a stable release, but I really hope we can fix this on a tooling
level.
Cheers,
Moritz
