Re: embedded modules at build time, and inc::latest best practice discussion

[intrigeri <intrigeri@debian.org>]

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