On 2020-05-22 16:30, Steve Grubb wrote:
Hello, I am working on our application whitelisting daemon. It uses the rpmdb to derive trust in what's on disk. If we use the whole rpmdb, then the number of files is large. So, to prune the amount of entries in the trust db down to a reasonable number, I thought we could jettison anything in /usr/share. According to the Filesystem Hierarchy Standard [1] it says this about /usr/ share: The /usr/share hierarchy is for all read-only architecture independent data files. But what I'm finding in practice is that cinnamon places its javascript there, there are libexec dirs that contain executable code, there are python and byte compiled python over there. In short, the system doesn't work because critical executables are in /usr/share. The question is what should be done about this? Do we care that things are in /usr/share that are not following the Filesystem Hierarchy Standard? If we do, what is the proper fix this this? Should bz be opened against each component?
Does "read-only architecture independent data" mean the files must not be programs? Javascript, Python scripts and Python bytecode are all read-only and architecture independent. And everything on disk is data. The document you linked explicitly gives troff macros and "perl" as examples of what goes in /usr/share/.
IMO, /usr/share/ would be a better place for *all* pure-Python modules than /usr/lib/, where they are now. The main reason they weren't moved is that the move would cause a lot of disruption.
1 - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html
_______________________________________________ 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
