On Mon, Jul 03, 2023 at 07:43:56AM +0200, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Darrick J. Wong (2023-06-30 17:51:28) > > On Tue, Jun 20, 2023 at 02:16:41PM +0200, Johannes Schauer Marin Rodrigues wrote: > > > If archive.h is available during compilation, enable mke2fs to read a > > > tarball as input. Since libarchive.so.13 is opened with dlopen, > > > libarchive is not a hard library dependency of the resulting binary. > > > > I can't say I'm in favor of adding build dependencies to e2fsprogs, > > since the point of -d taking a directory arg was to *avoid* having to > > understand anything other than posix(ish) directory tree walking APIs. > > this is why the build dependency is optional. As Ted said elsewhere, the big question is (a) do we really want e2fsprogs depending on libarchive at all, and (b) is libarchive's API stable enough that you'll maintain it for us? Merging this patch *is* adding to the complexity of what most distros consider to be critical system utility. > It should be perfectly possible > to build e2fsprogs without libarchive as well. I copied the pattern that was > already implemented for libmagic which is also not a hard dependency but gets > dlopened-ed at runtime. If this mechanism is fine for libmagic it should be > fine for others as well, no? > > The tar format (minus some features) is also not terribly complicated. Would There's at least five formats known to GNU tar, according to its manpage: Format UID File Size File Name Devn gnu 1.8e19 Unlimited Unlimited 63 oldgnu 1.8e19 Unlimited Unlimited 63 v7 2097151 8GB 99 n/a ustar 2097151 8GB 256 21 posix Unlimited Unlimited Unlimited Unlimited https://www.gnu.org/software/tar/manual/html_chapter/Formats.html > you prefer I add a rudimentary tar parser that will be used in the event that > libarchive is not available? The tar format is not that complicated but adding > such code to e2fsprogs would be overkill for a functionality that is otherwise > optional, no? Indeed not. > > > This enables the creation of filesystems containing files which would > > > otherwise need superuser privileges to create (like device nodes, which are > > > also not allowed in unshared user namespaces). By reading from standard > > > input when the filename is a dash (-), mke2fs can be used as part of a > > > shell pipeline without temporary files. > > What if the argument is actually a Microsoft CAB archive (which libarchive > > claims to support)? Will it actually copy the cab archive into an ext4 > > image? > > I didn't have a cab archive so I couldn't test this but it does work with other > archive formats like zip files. Would you like me to artificially restrict the > input format to only tarballs? No -- if Ted wants libarchive input for e2fsprogs, it may as well take full advantage of it. --D > Thanks! > > cheers, josch
