On Thu, Apr 18, 2019 at 09:32:06PM +0200, Hans-Christoph Steiner wrote: > > One possibility would be including libsparse as a patch, it doesn't > change a lot: > https://android.googlesource.com/platform/system/core/+log/master/libsparse > > But it depends on Android's libbase and libz-host.
This might be "serious" bug from the fastboot package's perspective, but there's no way in heck the release time is going to consider this a bug that is "serious" priority for e2fsprogs. More to the point, there's now way in the world I (or the release and installer teams) are going to make e2fsprogs, which is an "important=yes" package with priority "required" drag in the android-libsparse, android-libbase, and zlib1g packages. So the way you changed android-sdk-platforms-tools to use /sbin/mke2fs was a really bad choice, especially this while we are in release freeze for Buster. There's no way in the world we are going to make a change like this to a package like e2fsprogs which is used by the installer at this point. If we had more time, and if android-libsparse-dev shipped a static library, we could have considered statically linking in android-libsparse, android-libbase, and libz --- and see if they would bloat the mke2fs and debugfs binaries by only a minimal amount. This would also require making changes to e2fsprogs configure and Makefiles, since currently we only have support for linking in libsparse in the AOSP build files. The reason for this is historical; at the time when the intern working with Android team was working on replace Android's make_ext4fs program with mke2fs and e2droid, there was no distribution that was shipping libsparse, and trying to make libsparse available to Linux desktop environments was *way* beyond the scope of the Intern's project and time availability. We can work on this trying to find a solution post-Buster --- either using static linking, or *possibly* figuring out a way to optionally use dlopen() to pull in libsparse for sparse_io.c, much like the way libss optionally pulls in the readline library using dlopen at runtime, back when we cared about making mke2fs fit on a two 1.44 MiB boot/root install floppies. :-) Alternatively, you can build your own version of mke2fs using the libsparse from AOSP. If you want a solution that might make it in during the Buster release freeze, that's probably the short-term solution I would suggest. So your choice --- we can either reassign this bug back to fastboot or android-sdk-platforms-tools, or I can downgrade the severity of this bug for e2fsprogs down to wishlist[1]. Let me know how you want to handle this. Cheers, - Ted [1] This is because I view this both as a "feature request" and "bugs that are very difficult to fix due to major design considerations" (per https://www.debian.org/Bugs/Developer#severities), not to mention that it's going to affect a miniscule fraction of the e2fsprogs package's users.