[OE-core] Problems with INC_RPM_IMAGE_GEN

[Paul Eggleton]

Hi Qi,

On Monday 16 December 2013 12:29:14 ChenQi wrote:
> Recently I've enabled INC_RPM_IMAGE_GEN on my old and slow build
> machine. Here are two problems I can see with this feature.
> 
> 1. INC_RPM_IMAGE_GEN and 'rm_work'
> If we enable INC_RPM_IMAGE_GEN and 'rm_work' at the same time, we would
> get build failures.
> This is because the original rootfs has been removed because of rm_work.

We could perhaps now auto-set RM_WORK_EXCLUDE for images where 
INC_RPM_IMAGE_GEN is set, would that fix this?

> 2. INC_RPM_IMAGE_GEN and XXX_POSTPROCESS_COMMAND
> Let's first look at a case.
> 1. build core-image-minimal with 'extrausers' inherited and root
> password set in local.conf
> 2. build core-image-minimal without 'extrausers' inherited
> The image generated in the second step still has the root password set.
> This is not what we want.
> 
> The problem in incremental rpm image generation is that it chooses the
> final image as a starting point.
> However, the final image has been tweaked by all those
> XXX_POSTPROCESS_COMMAND.
> For example, the 'debug-tweaks' IMAGE_FEATURE will lead to several
> additonal ROOTFS_POSTPROCESS_COMMAND.
> meta/classes/image.bbclass:# Allow dropbear/openssh to accept logins
> from accounts with an empty password string if debug-tweaks is enabled
> meta/classes/image.bbclass:ROOTFS_POSTPROCESS_COMMAND +=
> '${@base_contains("IMAGE_FEATURES", "debug-tweaks",
> "ssh_allow_empty_password; ", "",d)}'
> meta/classes/image.bbclass:# Enable postinst logging if debug-tweaks is
> enabled
> meta/classes/image.bbclass:ROOTFS_POSTPROCESS_COMMAND +=
> '${@base_contains("IMAGE_FEATURES", "debug-tweaks",
> "postinst_enable_logging; ", "",d)}'
> 
> IMHO, the rootfs after all packages installed and before all postprocess
> commands running should serve as the reference rootfs for the
> incremental rpm image generation.
> But I cannot figure out a reasonable solution which doesn't have much
> performance impact.
> 
> Any idea or suggestion?

Probably we would have to take a copy of the rootfs at some point before this. 
To be honest though this incremental functionality has always seemed a bit 
fragile to me - what if a postinstall for a package makes changes to files in 
the rootfs installed by another package, and the second time around the 
package is removed but the package's postrm doesn't undo those changes (do we 
even run postrms during incremental rootfs generation)?

Cheers,
Paul