Hi, Quoting Josh Triplett (2020-09-29 06:39:40) > I think it would make sense to have as part of the documentation of hooks, > which goes hand-in-hand with an outline of mmdebstrap's operation and where > those hooks fit. For instance, I didn't know until this conversation that > mmdebstrap used a different mechanism to handle Essential than non-Essential.
agreed. > > Would it be useful in any scenario to keep those *.deb files? > > For caching, yes, to avoid downloading them more than once. If a user wants to avoid downloading packages multiple times, they can just use apt-cacher. > Would it be possible to use libapt for that, via one of its various bindings? I did not find an interface offering that functionality. > > $ sudo mmdebstrap --variant=apt --include='systemd-sysv udev' \ > > > --setup-hook='mkdir -p ./cache.ess "$1"/var/cache/apt/archives' \ > > > --setup-hook='sync-in ./cache.ess /var/cache/apt/archives' \ > > > --extract-hook="sync-out /var/cache/apt/archives ./cache.ess" \ > > > --essential-hook='mkdir -p ./cache.rest "$1"/var/cache/apt/archives' \ > > > --essential-hook='sync-in ./cache.rest /var/cache/apt/archives' \ > > > --customize-hook='sync-out /var/cache/apt/archives ./cache.rest' \ > > > unstable debian-unstable > > This is definitely at the level of complexity where it'd be *really > nice* to just be able to pass `--cache-debs cachedir`, without depending > deeply on the specific nuance of mmdebstrap's essential/non-essential > handling (and potential future changes to that). This is what the --hook-directory option is for. You put a directory somewhere, place scripts in it according to each hook and their order and then run mmdebstrap like with `--hook-dir cachedir` which is just as short as your example. :) > > You can upgrade ext2 to ext4 by using "tune2fs -O > > extents,uninit_bg,dir_index,has_journal" but I see that this would be of no > > use to you. > > Right, that won't actually convert how existing files are handled. That > would take an e2fsck run with specific options. And the initial > filesystem would need more space than the final one, requiring an > unecessarily large image. Correct. Thanks! cheers, josch
signature.asc
Description: signature
