On Wed, May 08, 2019 at 08:45:30AM +0200, Paul Gevers wrote:
> > 2. binNMU without full source upload for security-master.
> >
> > It's still not possible, and I don't know there's any effort to
> > change the dak.
> >
> > But I want to know how security team handles other static linked
> > languages, like rust, haskell, ocaml, etc.
>
> With respect to binNMU'ing, static linking is not a problem, only
> arch:all is. Most haskell (4 vs 1048) and ocaml (21 vs 233) aren't
> arch:all. haskell and ocaml have a framework in place to at least know
> the status in unstable/testing. See e.g. the "permanent trackers" at
> https://release.debian.org/transitions/ I don't know yet what this means
> for security support. Neither do I know what it means for rust.
There's the additional issue that ftp-master and security-master don't
share tarballs; binNMUs are only possible for packages which are on
security-master, so we'd need to do manual source uploads for every
affected go package.
> But most haskell and ocaml packages can be binNMU'd.
This issue has been around for Haskell and Ocaml for a long time, but it
hasn't been an issue in practice. Ideally we can use the same mechanism
found for Go, also for Ocaml or Haskell if the need should ever arise.
For Go it's different, it has already bitten us for the limited subset
of Go applications in Stretch (and #922170 which is needed to kludge
around it), but with the increased footprint of Go stuff in buster we
need something better.
The same issue will hit us with Rust as well, but for buster we have
only two relevant packages (librsvg and firefox which use vendored
libs, which seems manageable). For bullseye we also need a proper, generic
solution for Rust.
> I think the
> problem of the security team is that they don't want to commit to that.
Yeah, that won't work, this could amount to hundreds of packages.
Cheers,
Moritz
