Comment 101 for bug 1267393

Revision history for this message
Michael Terry (mterry) wrote :

> - reverse-dependencies don't have to be rebuilt for a security update to a
> C library; even if an API does break, C revdeps can be left unbuildable
> for a while with much less impact

I get that you're saying it's good because we don't have to waste security-update-time fixing reverse-depends. Which is a good point. But it also sorta sounds like "in this scenario, the advantage of C libraries is that we have unbuildable packages that we don't know about". So a bit of a mixed blessing.

> - since we're not using shared libraries (at this point), there's nothing
> in the packaging of go packages (like sonames for C libraries) that
> signals to proposed-migration that there's been an incompatible change
> requiring a transition.

For incompatible changes requiring transitions, I thought the Go convention was a new package name. Like check.v1 or check.v2. Which would be a whole new package in Debian/Ubuntu. Much like shared libraries bumping sonames.

--

So adding synthesized dep8 tests or proposed-migration logic to confirm no ftbfs by rebuilding Go reverse-dependencies are good ideas. But I maintain it's just as good an idea as doing the same thing for any other package upload (checking reverse-depends for ftbfs). The only difference I see is Steve's point about the security team being faced with ftbfs packages that they must now fix. Normal package updates wouldn't require a rebuild of all reverse-depends, so those would be status quo.

1) So, since the security team is facing this, I'll leave this specific question to them. They didn't mention monitoring for ftbfs in their list of requirements before, but maybe they'd like to? I guess the easiest route would be a golang-autopkgtest package like pitti mentioned.

2) Am I being too carefree? Do Go library minor updates tend to break builds more often than C or Python libraries? (Honest question, I'm not a Go native.) I had assumed Go folks have typical engineering practices, but maybe the statically-linked nature of Go causes people to play fast and loose with updates.