4585955a8b
Every run we are doing a full tar.gz of the chroot environment that never gets used. It's not suitable for CI since we use fresh images each time there. The cache in general isn't really isn't a very safe thing to have around, because there's no invalidation procedure and no real way to make one -- we've no guarantee that a new chroot build even moments after a previous one wouldn't bring in or different packages, etc (of course this is *unlikely*, but the longer you go between builds the worse the problem becomes. Also, tons of packages get installed after this not from any cache, so potential speed-up is rather marginal. Debian turned this off with I58fc485aacacaa17243bf9ce760ed91256d1f182. However, given the reasons above and it's complete lack of testing, I don't see this as useful. If we really want this type of thing, I think we should come up with a way to use a persistent external yum/dnf cache that yum/dnf keeps in sync with it's usual invalidation rules. Change-Id: I66789c35db75c41bc45ea1ad2e26f87456de4e4d
9 lines
483 B
YAML
9 lines
483 B
YAML
---
|
|
deprecations:
|
|
- The ``DIB_YUMCHROOT_USE_CACHE`` variable has been removed and the
|
|
Fedora and CentOS ``-minimal`` initial chroot will always be
|
|
created by the package manager. The default creation of a chroot
|
|
tarball is stopped for these elements. This unused option was
|
|
unsafe; there is no guarantee that the base system will not change
|
|
even between runs. Getting the package manager to reuse the cache
|
|
for the initial chroot install is future work.
|