On Fri, May 22, 2020 at 09:31:25PM -0400, Steve Grubb wrote: > My question now is how can we determine what is meant to be > executable by system applications vs examples and other cruft? (This might be > relevant to people minimizing systems/containers.) Theoretically the examples are a documentation, and a documentation should be marked in an RPM database with a documentation flag. RPM even has an ability to remove the documentation files when installing an RPM package. But the reality is that only the manual pages and the files packaged with a %doc RPM macro are marked so. E.g. Perl POD files are not marked, because there is no easy way of programming rpm-build to handle a custom files as a documentation. Of course these is the "other cruft" that has no flags. Another approach is the executable bit in a file mode. But it's not applied evenly. E.g. ELF shared libraries get the bit set, but static libraries are missing it. Also various languages (like Perl) do not mark their libraries (modules) with the bit. The meaning of the bit is that the file is a program with an entry point understood by the kernel program loader. You can e.g. program Linux to execute Windows executables by configuring binfmt_misc properly. So I guess you are after a yet another classification of files. > Could we ask that all of the executable code live inside a libexec dir and > examples under something else? Possible, but tedious. We would need to get a consensus among muplitple distributions and major upstreams. A decades long project. Installing files into the unexpected paths is questionable. Do you know about software collections (RHSCL product)? We packaged some software under /opt at the expense that users had to set the environment variables (PATH, LD_LIBRARY_PATH, MANPATH) to get them accessible. It was backslahed as too obtrusive way of using a software. Here we talk about patchnig every software to be eable to locate its files on a new location. I think maintaining a database of files, path prefixes, files name patterns, or some file flags in an the RPM database or extended attributes in the file system is an easier approach. Actually extended attributes are used by SELinux. Maybe augmenting SELinux would make sense. It already has tools for labeling files. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
