On Mon, Dec 11, 2023 at 12:53:00PM -0500, Stephen Smoogen wrote: > > > We could just have an /etc tree like we see now but in /usr/share/etc > > > (or /usr/etc, but then I get IRIX nightmares) and your local overrides > > > exist in /etc. Things like fstab will probably just have to always be > > > host-dependent so they will always exist in /etc. There isn't much real difference between /usr/share and /usr/lib. Officially /usr/share is for stuff that is "shared between architectures", but the approach of mounting in /usr/share and actually _sharing_ it between different systems separately from /usr has mostly gone away. Realistically, any location under /usr is going to share the same storage, become available at the same point during boot (very very early), and be ro/rw in the same way. So I guess individual projects will pick a specific location in a way that makes the the most sense to them. https://uapi-group.org/specifications/specs/configuration_files_specification/ says: "The precise location under /usr/ is left open for the implementation to decide - it could be hard-coded to /usr/lib/ or it could be left to each application to pick from various options, such as /usr/share/ or /usr/etc/." > > We're currently not allowed to use /usr/etc (not that I like that path > > anyway) because it breaks RPM-OSTree. My understanding is that this > > directory is reserved by RPM-OSTree for storing pristine copies of > > /etc content for each OSTree commit. Ah, that's a bummer. I think some projects are using /usr/etc, so this is going to become a problem. > My other problem with using /usr/etc is if we decide in N years that we > want to get rid of /usr altogether (reverse usrmerge so /usr/sbin -> /sbin, > /usr/bin -> /bin etc) and put everything at top-level.. we have to then > figure out where we would put all this content anyway. No, this is not going to happen. With /usr, the whole OS is a single mount point. So for example, it's easy to have a system where the OS is delivered as a dm-verity-protected signed read-only partition, and the root is a writable-fs-over-luks, created on the fly when the machine is first booted. With "reverse usrmerge", we get a bunch of directories which need to be handled separately, making things harder and less clean. It also doesn't bring any benefit, so I don't see why we'd want to go through the pain of a move. > At some point I think we are also looking at large enough changes that we > need to 'update FHS' and similar guidelines mainly so that third party > standards and tools can know where things 'should' go. FHS is alive as https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html (and the XDG standards for files under $HOME). I think that the recommendations there describe the consensus in the Linux ecosystem. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
