On Wed, Jan 19, 2022 at 3:04 AM Petr Pisar <ppi...@redhat.com> wrote: > > V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a): > > Since /var should contain only files that can be safely removed, > > While I agree with your change, this statement is false. /var is for any files > which are variable. Files which can be safely removed belong to /var/tmp and > /var/cache.
Either /etc or /var should contain files that can be safely removed, i.e. the system or application shouldn't break. Anything needing some sort of base state information to function at all, needs to put that in /usr, and customization/modification results in it being written to /etc (configuration) or /var (runtime variable state information). So if the files in question being moved were to be deleted, authselect needs to handle that potential regardless of whether the state information is in /etc or /var. From FHS 5.8.1 about /var/lib "State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application." If anything is more likely to get wiped in a factory/system reset, I think it's /etc. I expect upon configuration information being reset, that by extension the variable state information is rendered unreliable or useless. Conversely, upon wiping a program's /var/lib information, the configuration information in /etc is not inherently invalid. I don't see much information in the FHS about the expected behavior or consequences of wiping either location. But I think as a distribution we can have the opinion the programs that face plant upon finding empty /etc or /var/lib still should have the ability to self-configure from /usr - be it a built-in process or some upstream default /usr/etc configuration or base state information in /usr/var - customization of either means populating the proper /etc or /var/lib FHS 3.7 is pretty clear that /etc is for configuration information, no binaries. I'm not completely sure I agree that state information is disallowed in /etc, although I think the intent of the FHS here is so that users can ostensibly reset a program's persistent state by wiping the program's /var/lib information, which wouldn't alter its configuration. If it's possible such a scenario confuses the program, it really needs to be better prepared for this potential. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
