avoiding extracting rpmdb from base image

[cgwalters]

Extract installed packages from a container image. This would be used for layered images.

I think we should instead accept one of several declarative input formats. This is discussed in hermetoproject/cachi2#465

Trying to extract after the fact just makes everything circular.

[lubomir]

This is not extraction of what to resolve. It's about figuring out what is already installed in the base image (i.e. copying out the rpm db). That can not easily be declared elsewhere (unless you work with a very narrow subset of base images).
Another alternative is to run the depsolving inside the container, which gets complicated quite quickly.

[cgwalters]

You’re right sorry. However there is an alternative implementation: Add the machine-readable declarative input used to generate the base image into its metadata. Today for UBI it’s a kickstart. Then we just need the immutable yum repo versions used and that should be sufficient to know what is in the base. (If the base switches to lock files as used in this prototype we could just stick that whole thing in metadata but - to connect with the other thread I think “immutable versioned repos” is far more ergonomic and readable than lock files.) Of course in the general case this needs to support multiple layers, and changes(upgrade, downgrade, removal) from prior layers. So the metadata key would need to be an array, a bit like the “history” metadata in the config.

[lubomir]

I completely agree that there are better ways to solve this problem as long as the base image is cooperating.

The current implementation is problematic on many fronts (hard to run in container, inefficient…).