-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move content in /opt
to /usr/lib/opt
as part of ostree container commit
if state overlays enabled
#573
Comments
That would conflict though with the existing logic in 495988e |
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 |
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 |
/opt
to /usr/lib/opt
when importing container image if state overlays enabled/opt
to /usr/lib/opt
as part of ostree container commit
if state overlays enabled
Obsoleted by #607 (comment). We don't need to move the content to |
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/[email protected]
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).The text was updated successfully, but these errors were encountered: