Move content in /opt to /usr/lib/opt as part of ostree container commit if state overlays enabled

[jlebon]

As part of ostreedev/ostree#3120 and coreos/rpm-ostree#4728, packages which install to /opt are converted to /usr/lib/opt/ by the importer. To mesh with this, imported container images need to also do this translation. It can know if a system is configured for state overlays on /opt by checking if /usr/lib/systemd/system/local-fs.target.requires/ostree-state-overlay@usr-lib-opt.service is defined.

(Or alternatively, the code can automatically enables this service if it detects content in /opt. That way, users can leverage this stuff before the base image compose actually enables the opt-usrlocal-overlay knob).

[cgwalters]

Or alternatively, the code can automatically enables this service if it detects content in /opt.

That would conflict though with the existing logic in 495988e

[cgwalters]

Querying systemd units while fetching, or when deploying an image feels...a bit icky. A layering violation in a way.

I would perhaps lean a bit towards doing this as part of RUN ostree container commit - i.e. the container content is fixed up at build time, not client side.

[jlebon]

I would perhaps lean a bit towards doing this as part of RUN ostree container commit - i.e. the container content is fixed up at build time, not client side.

Sounds good to me. I guess if we start assuming this in the future (because it's just always on in the base compose), we could move it to the tar processing step. At that point, it'd purely a mechanical move, just like the /var to /usr/share/factory/var move.

[jlebon]

Obsoleted by #607 (comment). We don't need to move the content to /usr/lib/opt if we don't care about the non-composefs case.