Symlinking /usr/local and /opt into /var makes it harder to derive a build from a Fedora image #126

New issue

Open

opened 2026-08-31 06:00:14 +00:00 by gordonmessmer · 2 comments

gordonmessmer commented

2026-08-31 06:00:14 +00:00

/usr/local and /opt are symlinked to /var. This configuration is not recommended by the bootc documentation, except for "final" images that are not intended for use by derived builds:

https://bootc.dev/bootc//filesystem.html#usrlocal

The /usr/lib/tmpfiles.d/rpm-ostree-0-integration-opt-usrlocal.conf file also seems to describe the symlink-to-var configuration as a legacy configuration:

# Traditionally, /usr/local has been a link to /var/usrlocal and /opt to /var/opt.
# A new model now is to allow OSTree commit content in those directories. But
# this dropin implements the old model.

The practice of relocating those directories to /var makes sense if they are empty, but images that ship with anything in either location will be unable to update that content. Some users might choose to enable an overlay, and other might ship intentionally read-only content. Both of those approaches require reverting the symlink to var.

/usr/local and /opt are symlinked to /var. This configuration is not recommended by the bootc documentation, except for "final" images that are not intended for use by derived builds: https://bootc.dev/bootc//filesystem.html#usrlocal The `/usr/lib/tmpfiles.d/rpm-ostree-0-integration-opt-usrlocal.conf` file also seems to describe the symlink-to-var configuration as a legacy configuration: ``` # Traditionally, /usr/local has been a link to /var/usrlocal and /opt to /var/opt. # A new model now is to allow OSTree commit content in those directories. But # this dropin implements the old model. ``` The practice of relocating those directories to /var makes sense if they are empty, but images that ship with anything in either location will be unable to update that content. Some users might choose to enable an overlay, and other might ship intentionally read-only content. Both of those approaches require reverting the symlink to var.

👍 1

siosm commented

2026-09-03 14:25:44 +00:00

Owner

But I don't think we should change that for the Atomic Desktops. The images are both "final" and derivable. No packages in Fedora should write in those folders. Any derived build can modify that setting of they want to.

As I wrote in https://discussion.fedoraproject.org/t/are-opt-and-usr-local-symlinks-on-silverblue-because-it-is-an-ostree-image-and-not-bootc/199320/2, changing this behavior requires finding a migration path for existing systems. But I don't think we should change that for the Atomic Desktops. The images are both "final" and derivable. No packages in Fedora should write in those folders. Any derived build can modify that setting of they want to.

gordonmessmer commented

2026-09-03 22:10:43 +00:00

Author

I wonder if a reliable migration path is possible. I've read https://github.com/coreos/fedora-coreos-tracker/issues/1681

(The problem with the common suggestion of symlinking things that need to be writable is that there's a lot of bad but widely used software. It's common for applications to write to files in their application directory. And symlinking doesn't work if they write a temp file and rename in order to perform an atomic update to those files. For a bunch of applications, an overlay is the only reasonable approach. I understand that we might not want to support those applications, directly, but I dislike the idea that derived builds have to undo changes that we make in order to reuse our software.)

Anyway, on migration: Would it be possible to detect the redirected locations (e.g. /var/opt) and to move those to the overlay's path? I think we could do that before local-fs.target and only if the overlay doesn't exist, or after local-fs.target and only if the overlay's directory is empty. Both paths should be in /var so there shouldn't be any need to copy files, and therefor I think there's no risk of running out of space and leaving the migration unfinished.

I wonder if a reliable migration path is possible. I've read https://github.com/coreos/fedora-coreos-tracker/issues/1681 (The problem with the common suggestion of symlinking things that need to be writable is that there's a lot of bad but widely used software. It's common for applications to write to files in their application directory. And symlinking doesn't work if they write a temp file and rename in order to perform an atomic update to those files. For a bunch of applications, an overlay is the only reasonable approach. I understand that we might not want to support those applications, directly, but I dislike the idea that derived builds have to undo changes that we make in order to reuse our software.) Anyway, on migration: Would it be possible to detect the redirected locations (e.g. /var/opt) and to move those to the overlay's path? I think we could do that before local-fs.target and only if the overlay doesn't exist, or after local-fs.target and only if the overlay's directory is empty. Both paths should be in /var so there shouldn't be any need to copy files, and therefor I think there's no risk of running out of space and leaving the migration unfinished.