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@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
