Theodore Ts'o: > 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.
Makes sense to me. I'm fine with this being done post-Buster or as a custom mke2fs in android-platform-system-core. .hc
