RFE: Provide mount API to copy content from the container. Specifically /opt content.

[jmarrero]

Some users have applications that install under /opt. Existing approaches and their trade-offs are discussed in Discussion #1038.

When /opt resolves to persistent /var/opt, whether through a symbolic link or a bind mount, its contents become persistent, user-managed state. Application content initialized there during installation is therefore not replaced during subsequent bootc switches or upgrades.

We do not want to change bootc’s contract: bootc should not modify or merge /var after installation. Doing so could overwrite user data and create ambiguous rollback behavior.

However, bootc could provide a supported mechanism for accessing selected content from the booted or staged container image. An application or administrator could then either copy that content into /var or
mount and consume it directly.

A conceptual interface might be:

bootc image mount
--deployment booted
--source /opt/example-agent
--target /run/example-agent-image
--read-only

An application-specific migration service could then copy it:

rsync -a
/run/example-agent-image/
/var/opt/example-agent/

Alternatively, the image content could be mounted directly at an explicitly selected location under /var:

bootc image mount
--deployment booted
--source /opt/example-agent
--target /var/subdir/example-agent-image
--read-only

The application could use this location for its immutable binaries while keeping configuration, logs and other writable state elsewhere under /var.

This preserves the existing ownership contract:

• bootc does not merge, delete or overwrite persistent /var content.
• Image content is exposed read-only.
• The administrator explicitly selects both the source and target.
• Applications own any synchronization or migration policy.
• Rollback and persistent-state compatibility remain application decisions.

The API should define:

• Access to both booted and staged deployment content.
• Read-only enforcement.
• Whether the target must be an empty mount point.
• Mount lifetime and explicit unmount behavior.
• How the mount is recreated during boot.
• Integration with systemd service ordering.
• Behavior when the source path does not exist.
• Behavior when the original container image is no longer locally available.
• Upgrade and rollback semantics.

A possible systemd integration could look like:

[Unit]
Description=Expose image-owned agent content
Before=example-agent.service
RequiresMountsFor=/var/subdir

[Service]
Type=oneshot
ExecStart=/usr/bin/bootc image mount --deployment booted --source /opt/example-agent --target /var/subdir/example-agent-image --read-only
RemainAfterExit=yes
ExecStop=/usr/bin/bootc image unmount /var/subdir/example-agent-image

[Install]
WantedBy=multi-user.target

The goal is to make content already delivered through the bootc image accessible without:

• Automatically modifying /var.
• Pulling the same image again with Podman.
• Requiring applications to duplicate their complete payload elsewhere in the image.

[cgwalters]

xref #542 (comment)