This feature is going to cause a lot of churn. Aside from the huge changes within fedora I think a bigger issue will be downstream of fedora where third party packages and configs will require large changes. I would worry we might alienate our users a bit with this? Now I'm all for clean up, but sometimes it may have to be done piecemeal for pragmatic reasons. Could someone please enlighten me on the functional benefits of moving everything to /usr? I can see the clean up benefits of splitting things by mutability/persistence, with the proposed scheme being: /etc - non-shareable, can be read-only, host-only configuration /usr - shareable, can be read-only, package managed, binaries /var - non-shareable, writable, host-only state/data /run - temporary state However the existing hierarchy can be quite easily adjusted. For example I previously worked with a Fedora 14 system on installations of up to 1000 systems that were organized like: /tmp - temporary state (rw) (ram) /var - host state (rw) (nfs) /etc/dev - device state³ (rw) (local disk/flash etc.) /... - the rest¹ (ro²) (nfs) ¹ The rest was a single file system. I've never mounted /usr as a separate file system anyway. ² Note there were a few places in the rest of the hierarchy that needed to be bind mounted to the (rw) locations, but they were minimal and encapsulated in /etc/statetab.d/blah Also it seemed quite elegant in the case of /etc for example to have all the config together, with only a couple of places auto bind mounted to (rw). ³ Stuff like touchscreen calibration settings. Also about snapshots. This is possible (better?) when done from the source location. I.E. in my example above, the (ro) nfs directory was easily copied or directed to a new release directory. For local systems the equivalent would be doing a snapshot of the (ro) file system at the file system level (like BTRFS supports), rather than going down through the file hierarchy which seems inefficient and racy. cheers, Pádraig. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
