Dear maintainer,

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'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.

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?

* --second-stage - Similar to above.

* --no-check-gpg - Not sure worth bothering or if you would like to
support that for compatibility's sake.

Thank you for maintaining mmdebstrap, it's an amazing tool!

Kind regards,
Patrick

[1] live-build: support configuration of debootstrap binary
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031929

Hi,

Quoting Patrick Schleizer (2023-02-25 15:48:00)

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.

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?

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.

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?

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

Johannes Schauer Marin Rodrigues:

No, unfortunately not.

Understood.

However, all the options I suggested could be considered "accept these
option, do not bail out, and simply do nothing about these options". In
other words, if --foreign is set, simply ignore it. That is, if that
seems appropriate.


Towards debootstrap drop-in comparability only.

Kinda, if it appropriate do everything in the first stage, do it. And
later if mmdebstrap is called with --second-stage is run, simply say
"not needed, mmdebstrap doesn't need a second stage, all done" exit 0
and do nothing. (Or the other way around.)

I don't know any where --no-check-gpg is currently useful except for
completeness sake of supporting the same (or as many as possible)
options as debootstrap. In case --no-check-gpg is given, simply ignore
it and don't bail out due to unknown option.

Yeah. That's the general theme of my reply. Accept the option in
mmdebstrap option parser but don't implement/change any actual
functionality. Just the options parser giving it a pass and then ignored.

Hi,

Quoting Patrick Schleizer (2023-03-13 12:19:00)

okay. In the mmdebstrap codebase you see lines like these:

  'force-check-gpg' => sub { push @{ $options->{noop} }, 'force-check-gpg'; },

The above example adds the --force-check-gpg as a no-op option to mmdebstrap.
How about you try adding more of these as appropriate and try out how far you
get?

For me this is backwards. Why should not instead debootstrap learn to do the
right thing instead of this two-stage process?

This would require mmdebstrap to write out a script into the chroot that can
then be later called with --second-stage. This seems overkill just for
compatibility with an inferior piece of software.

Would it not be a much better investment of your or my time to teach lb how to
call mmdebstrap properly instead of forcing something onto mmdebstrap that
makes it worse?

Maybe you can provide a patch that shows that what you propose works?

Thanks!

cheers, josch