Le 2025-01-22 21:15, Phil Wyett a écrit :
ratt (“Rebuild All The Things!”) operates on a Debian .changes file of
a just-
built package, identifies all reverse-build-dependencies and rebuilds
them with
the .debs from the .changes file.
The intended use-case is, for example, to package a new snapshot of a
Go
library and verify that the new version does not break any other Go
libraries/binaries.
ratt need not be run against architecture 'all' packages, so for these
it will
be a 'N/A' result.
Java libraries are architecture:all, and some updates are breaking
builds (typical causes are that some artifact got renamed, that a
deprecated API got finally removed, or sometimes plain old API/ABI
incompatibilities). Why should they not need this?
The issue I have with that new test (and also with autopkgtests to some
extent) is that the so-called "regressions" are automatically attributed
to the updated package. This is fair as long as the update is expected
not to break things, and while some upstream projects are reasonably
conservative in their attempts to keep things compatible, for some
others it's clearly not among their priorities.
Also some packages may have many reverse dependencies, and some that are
fairly heavy to build and test. Expect a few cases to need several hours
to complete the rebuilds on a dedicated system.
But I think it's a good thing to know in advance which packages (if any)
are going to be broken by an update, and to notify their maintainers as
a courtesy, eventually telling them what they are expected to update.
Cheers,
--
Julien Plissonneau Duquène
