Hi,

On Sun, 2026-02-08 at 22:12 -0800, AshishKumar Mishra via lists.openembedded.org wrote:
Hello Community Members  , 
 
I would like to propose a change to how we handle sparse image generation for ext* file-systems in OpenEmbedded, 
specifically moving away from the generic img2simg tool toward the specialised ext2simg in the e2fsprogs [contrib/android]

Firstly, you should probably mention that image_types_sparse is in meta-oe, not oe-core. You should therefore probably mention this on the list where meta-oe is maintained too.

1) Problem
Currently, image_types_sparse.bbclass uses img2simg for all file-system types. 
img2simg is a  tool that reads the raw image to find zero-filled blocks. 
For ext* file-systems, this is inefficient compared to  ext2simg from e2fsprogs [contrib/android]
which understands the file-system structure and uses the block bitmap to determine sparse areas.

That seems reasonable.

2) History
Previously, 'ext2simg' was bundled within android-tools (v5.1 and older).
The utility has since migrated to the e2fsprogs project (contrib/android).
However, upstream e2fsprogs does not provide a build system for this tool,
and it requires libsparse from android-tools to compile.
 
 
3) Proposed Changes
To implement this, I am looking at a cross-layer approach:
 
a. meta-oe (android-tools):
Export libsparse, libbase, and liblog headers and libraries to the sysroot. Currently, these are often internal to the build.
Reorganise header installation to ${includedir}/sparse to match the expected include paths for e2fsprogs contrib tools.
 
b. oe-core (e2fsprogs):
Add a conditional compilation step in e2fsprogs-native to build the ext4sparse utility located in contrib/android/.
This would link against the exported libsparse from android-tools-native.
 
c. meta-oe (image_types_sparse.bbclass):
Update CONVERSION_CMD:sparse to detect ext* types.
Use  ext2simg from the e2fsprogs [contrib/android] for these types while falling back to img2simg for others (like f2fs).
 
 
4) Points for Discussion / Feasibility
     I am seeking feedback on the following:
 
a. Layer Dependency: 
This introduces a tighter coupling between oe-core and meta-oe. 
Is it acceptable for e2fsprogs-native (core) to optionally depend on android-tools-native (meta-oe), 
or i can create an bbapend file in meta-oe called e2fsprogs_%.bbappend. 

oe-core cannot depend on meta-oe.

The bbappend is one approach but it means e2fsprogs would rebuild whenever a layer is added/removed and it would likely fail the yocto-check-layer tests. It would also mean anything depending on e2fsprogs would also rebuild and sstate would not be reused. None of this is particularly good.

Instead, how about a separate recipe, e2fsprogs-ext4sparse which just builds this utility?

Cheers,

Richard