Re: embedded modules at build time, and inc::latest best practice discussion
Hi,
gregor herrmann:
> Traditionally, while we were always unhappy about copies of perl
> modules in inc/, we just held our noses and used them (unless they
> were old/buggy).
> […]
> Or maybe only inc::latest is a problem as it leads to kind of
> unpredictable builds (different versions used)?
Wrt. build reproducibility I think that's not a problem: two builds of
the same source package are only expected to result in the same binary
packages if the set of (build-dep, version) tuples is identical.
For inc::latest to cause trouble one needs to build in two
environments with different versions of the build-deps, so that'll be
recorded in the .buildinfo file and we're expecting we may get
different build artifacts.
I've tried to imagine other cases where build-deps vendorized with
inc::latest can create significant confusion. tl;dr: the one I've
found requires a sequence of events that's unlikely to happen often in
the Perl ecosystem (most Perl library authors are not into the habit
of making incompatible changes to the API every time they brush their
teeth).
For the curious only, here's one I found:
1. Someone prepares a package, it passes its built-time tests and
autopkgtests, upload, boom. Say both the version of the build-dep
that's in the archive and the vendorized version work just
fine here.
2. I import a new upstream release that updates the vendorized
build-dep to a version newer than what we have in the archive.
I don't read the comments in debian/control or whatever else there
might be some indication that I should be careful. Tests pass at
build time ("thanks" to inc::latest) but autopkgtests fail (they
don't use the vendorized version). I might spend a non-negligible
amount of time understanding what's going on. That's a problem.
Worse, it might happen that I fail to understand and disable the
failing test for autopkgtests as "upstream test suite not
compatible with runtime testing, for some reason I don't
understand"; fair enough, we don't expect 100% of upstream test
suites to work in that environment, so let's say I do that
and upload.
3. At any point in the future, the package may start FTBFS'ing,
without any change in the source package, due to the aforementioned
test failing because we've uploaded yet another incompatible
version of the build-dep, that's newer than the vendorized one.
That's business as usual in a distro but thanks to autopkgtests,
normally we would have a track record of what exact build-dep
update broke things. Sadly, in this case, there's a good chance we
don't notice this easily: we don't rebuild the archive regularly
and autopkgtests will have kept passing with flying colors because
I've disabled the very test we would have needed to spot the source
of the problem.
Cheers,
--
intrigeri
Reply to: