On Sat, Sep 26, 2020 at 07:28:57AM +0200, Johannes Schauer wrote: > Quoting Josh Triplett (2020-09-26 06:28:18) > > mmdebstrap seems to re-download packages every time it runs. I'd love to > > have > > a way to cache those packages, so that it can run substantially faster the > > second and subsequent times. > > Do one thing and do it well. > > I'm sure you are aware of apt-cacher or apt-cacher-ng? > > In other situation, for example the mmdebstrap testsuite, I built my own > caching mechanism: > > https://sources.debian.org/src/mmdebstrap/0.7.1-1/make_mirror.sh/ > > Adding a cache is so simple, you can use a snippet of Python from this pull > request of mine: > > https://salsa.debian.org/debian/devscripts/-/blob/d1c6f2f6a3dca51b77a4a9b37c7d68c1d69270dd/scripts/debbisect#L113 > > But why add it to mmdebstrap? That just adds additional complexity and feature > creep. It makes an already complex tool even more complex. Why not keep this > functionality in an additional piece of software? > > Please convince me.
I'm definitely not proposing integrating a caching proxy of any kind into mmdebstrap; that should absolutely be a separate piece of software. But a caching proxy doesn't solve the problem for me. Using a caching proxy would require one or both of: - Using http, rather than https - Configuring the target system to use the proxy directly in its config What I was hoping to see integrated into mmdebstrap would be support for just directly copying the relevant files into the target's /var/cache/apt, where apt could use them rather than re-downloading them. Such files could either come from the host system's /var/cache/apt, or from a directory given to mmdebstrap as a command-line option (where the latter would also allow mmdebstrap to store files from the target's /var/cache/apt before deleting them). I'm hoping that has the right combination of "sufficiently narrowly scoped" and "requires integration" to make sense as a part of mmdebstrap.
