Hi, Quoting Patrick Schleizer (2023-02-25 15:48:00) > live-build's `lb build` uses some command line options which are > unsupported by mmdebstrap. > > live-build currently doesn't support configuration of the debootstrap > program [1] but until/if it does, I simply used "sudo cp > /usr/bin/mmdebstrap /usr/sbin/debootstrap". mmdebstrap attempts to be a > debootstrap drop-in replacement as far as I understand so that should work.
it tries a little bit. By definition, mmdebstrap can (and shouldn't) by a 100% drop-in replacement for debootstrap. If I wanted to make it one, we would loose some of the most important features that make mmdebstrap superior to debootstrap as listed in the man page. But it tries a little bit. At the end of the man page you will see some no-op options which mmdebstrap has but which do nothing just so that it can be called by a script expecting some debootstrap-like behaviour. For example, it works as a drop-in replacement in sbuild-createchoot which traditionally uses debootstrap. > It's currently broken because `lb` uses (at least) the following > parameters which are unsupported by mmdebstrap: > > * --download-only > > By looking at the source code of live-build I am reasonably sure, this > might only be happening because I previously set: > `lh config --cache-packages true` > > That 'lb config' option however may or may not be redundant since > mmdebstrap might cache itself by default. Nevertheless would it be nice > if this could be fixed please. This will be difficult. There are quite few semantics of the --download-only option of debootstrap that mmdebstrap would have to copy 1:1 for this to work. Are you familiar enough with lb to discuss this problem? > While at it, there are some other debootstrap related command line > options that I found in the live-build source. These might come up later > in other corner cases that mmdebstrap doesn't support yet: > > * --foreign - Only used for the live-build's qemu-debootstrap related > code path. But perhaps worth supporting too? There is no need for that option because mmdebstrap automatically does the right thing if you instruct it to create a foreign architecture chroot without you having to manually tell it that the architecture is foreign. Another problem of the debootstrap --foreign option is, that (due to debootstraps limitations) leads to debootstrap getting interrupted right after downloading and extracting the packages and then expects that one chroots into that directory and calls /debootstrap/debootstrap --second-stage. All of those workarounds are not necessary with mmdebstrap as it will do the right thing for foreign architectures from the start. > * --second-stage - Similar to above. Why should I add this extra complexity of what debootstrap does in its second stage to mmdebstrap if mmdebstrap doesn't even need it because it does the right thing already? > * --no-check-gpg - Not sure worth bothering or if you would like to > support that for compatibility's sake. This is not really possible with mmdebstrap in all cases because mmdebstrap is using apt to create the chroot and even with [trusted=yes], apt will still run gpgv and do checks that cannot be disabled as of today. For this to work reliably, more code needs to be added to apt. I've talked with apt maintainers about this in the past about this but they (understandably) say, that the risk of doing something wrong in such important code paths (security-wise) is too high to allow for completely disabling gpg checks. In which situation would --no-check-gpg be useful? Thanks! cheers, josch
