Quoting Trent W. Buck (2019-10-10 11:31:37)
> It would cool if I could do an unprivileged mmdebstrap and get a .squashfs
> instead of a tarball.

I agree. That would be very cool!

Unfortunately, I think there are some complications:

 1. mmdebstrap can work completely without superuser privileges because in the
    end the output is just a file containing a certain arrangement of bytes and
    there is no sensible reason why one should need root privileges to figure
    out the right arrangement of bytes. This is easily possible with the tar
    output format because how the right arrangement of bytes for device nodes
    for example has to look like can easily be produced without being root.
    This is not possible with mksquashfs as it requires the files it packs to
    actually exists beforehand.

 2. mmdebstrap allows to produce its output on stdout but mksquasfs can only
    output to either a block device or a regular file.

 3. as you noted, squashfs is read-only, so mmdebstrap would need yet another
    command line argument so that the user can specify which paths they do not
    want in the final image. More CLI options mean yet more complexity and
    longer documentation. With tar as output format we don't need such an
    option because we can just do:

       $ mmdebstrap unstable - | tar --exclude=./dev > out.tar

 4. mksquashfs has a ton of options which somehow have to be exposed via
    mmdebstrap which means yet even more CLI options and more complexity

What we could do is to add squashfs support for all the cases where the above
does not apply, so namely when mmdebstrap is run as root and the output is to
be placed into a file. Namely when doing this:

    $ sudo mmdebstrap [...] unstable-chroot.squashfs

But this also adds a bunch of complexity to an already very complex codebase
because now we will need even more exception handling, error printing and
documentation which exactly details what conditions have to be met for direct
squashfs output. And then there is also the question of about all the
additional options we will need to change compression type block size etc...

Would it not help many more users if there was a tar2squashfs command which
could also read from stdin? That command could then be used by an even wider
audience for even more purposes.

I agree squashfs is great but with the current tooling around it forbidding
piping and root-less operation, it is not quite the perfect output format for
mmdebstrap as tar is.

So maybe you should rather approach mksquashfs upstream and talk about allowing
tarballs as input? Sales pitch: you could create a squashfs with files owned by
root without ever having needing root privileges. :)


cheers, josch

Attachment: signature.asc
Description: signature

Reply via email to