On Tue, Oct 13, 2015 at 05:33:37PM -0000, Michael Terry wrote:
> Though in this respect, golang isn't so different than C libraries, where
> an unexpected API update or library bug can cause ftbfs in
> reverse-depends.
It is different, because:
- 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
- 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.
> But actually, I expected we could use Built-Using fields in our
> proposed-migration tooling to automatically test that reverse-depends
> could still build. Is that not in the works yet?
I'm not aware that anyone has discussed integrating such functionality into
proposed-migration.
On Tue, Oct 13, 2015 at 05:33:37PM -0000, Michael Terry wrote:
> Though in this respect, golang isn't so different than C libraries, where
> an unexpected API update or library bug can cause ftbfs in
> reverse-depends.
It is different, because:
- 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
- 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.
> But actually, I expected we could use Built-Using fields in our
> proposed-migration tooling to automatically test that reverse-depends
> could still build. Is that not in the works yet?
I'm not aware that anyone has discussed integrating such functionality into
proposed-migration.