Closed jlebon closed 6 months ago
Or alternatively, the code can automatically enables this service if it detects content in /opt.
That would conflict though with the existing logic in https://github.com/ostreedev/ostree-rs-ext/pull/570/commits/495988e5115311703aed00eabc67807e0a79bb56
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.
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.
Obsoleted by https://github.com/ostreedev/ostree-rs-ext/issues/607#issuecomment-1973476187. We don't need to move the content to /usr/lib/opt
if we don't care about the non-composefs case.
As part of https://github.com/ostreedev/ostree/pull/3120 and https://github.com/coreos/rpm-ostree/pull/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 theopt-usrlocal-overlay
knob).