Re: [PATCH v3 0/5] Improving apt cache

["Roberto A. Foglietta" <roberto.foglietta@gmail.com>]

On Mon, 30 Jan 2023 at 11:45, Henning Schild <henning.schild@siemens.com> wrote:
>
> Am Mon, 30 Jan 2023 09:45:45 +0100
> schrieb "Moessbauer, Felix (T CED INW-CN)"
> <felix.moessbauer@siemens.com>:
>
> > On Fri, 2023-01-20 at 08:31 +0100, Uladzimir Bely wrote:
> > > Currently, apt cache (e.g. `var/cache/apt/archives`) import and
> > > export
> > > functions are not optimal. Multiple files are copied from global
> > > DL_DIR to package WORKDIR, increasing disk IO and space needed.
> > >
> > > Also, various chroots (bootstrap, buildchroot, sbuild chroot)
> > > include their apt caches to sstate cache files.
> > >
> > > This patchset switches to hardlinks instead of copies and removes
> > > apt cache from bootstrapped images ans sstate caches.
> >
> > I just saw that this pattern does NOT work in case the cache is on a
> > different filesystem. This unfortunately is the case for all CI
> > systems with locally mounted caches, as well as for kas-container
> > builds with DL_DIR outside the KAS_WORK_DIR.
>
> I remember discussing that issue with someone because that is always
> what happens when you implement hard linking. Not sure it was on the
> list because i kept away from this lively discussion.
>
> It is like when someone adds overlayfs and then finds that it can not
> be nested a few weeks later ;).

The overlayfs is not the right way to go because a simpler approach
should prefered. The problem of going for straight simple solutions
(small patches) is that in the long run this brings us to an
overcomplicated system. So, from time to time, it is necessary to
approach the problem from a radical point of view. This is not because
a radical change would be necessary but because we need to re-think
the system and then see how options are viable and then take a choice
among them balancing our choice between various aspects.

Best regards, R-