53456730bf
Today, lockfiles only restrict the NEVRA of specifc package names from which libsolv can pick. But nothing stops libsolv from picking entirely different packages which still satisfy the manifest requests. This was mostly a theoretical issue in Fedora CoreOS, but became reality with the addition of Fedora 32 packages in the pool. libsolv would happily try to pick e.g. `libcurl-minimal` from f32 instead of sticking with the f31 `libcurl` from the lockfiles: https://github.com/coreos/fedora-coreos-streams/issues/75#issuecomment-610734584 (But more generally, see https://github.com/coreos/fedora-coreos-tracker/issues/454). Let's add a `--ex-lockfile-strict` mode, which in CI and production pipeline build contexts will require that (1) *only* locked packages are considered by libsolv, and (2) *all* locked packages were marked for install. One important thing to note here is that we don't short-circuit libsolv and manually `hy_goal_install` lockfile packages. We want to make sure the treefile is still canonical. Strict mode simply ensures that the result agrees with the lockfile. That said, even in developer contexts, we don't want the `libcurl-minimal` issue that happened to be triggered. But we still want to allow flexibility in adding and removing packages to make hacking easier. I have some follow-up patches which will enable this. |
||
|---|---|---|
| .. | ||
| check | ||
| common | ||
| compose | ||
| ex-container-tests | ||
| gpghome | ||
| kola/nondestructive | ||
| manual | ||
| utils | ||
| vmcheck | ||
| compose.sh | ||
| ex-container | ||
| README.md | ||
| vmcheck.sh | ||
Tests are divided into three groups:
-
Tests in the
checkdirectory are non-destructive and uninstalled. Some of the tests require root privileges. Usemake checkto run these. -
The
composechecktests currently require uid 0 capabilities - the default in Docker, or you can run them via a user namespace. They are non-destructive, but are installed.To use them, you might do a
make && sudo make installinside a Docker container.Then invoke
./tests/compose. Alternatively of course, you can simply run the tests on a host system or in an existing container, without doing a build.Note: This is intentionally not a
Makefiletarget because it doesn't require building and doesn't use uninstalled binaries. -
Tests in the
vmcheckdirectory are oriented around using Vagrant. Usemake vmcheckto run them. See alsoHACKING.mdin the top directory.
The common directory contains files used by multiple
tests. The utils directory contains helper utilities
required to run the tests.