Hello, On Friday, May 22, 2020 6:38:55 PM EDT Kevin Kofler wrote: > > 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? > > /usr/share is the correct place for architecture-independent files, > including binaries and scripts. Though in principle, files that are > executable directly (+x bit set) should be in /usr/libexec (if they are to > be executed only by programs) or /usr/bin (if they should be executable > directly by the user) rather than /usr/share. But they may load additional > architecture-independent code (e.g., libraries, modules, plugins) from > /usr/share. Over a couple emails I kind of realized that originally this was framing the question wrong. 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.) Could we ask that all of the executable code live inside a libexec dir and examples under something else? As an outsider with no knowledge of the packaging history, how do you know the intent? That's it in a nutshell. -Steve > /usr/lib is actually the wrong place for architecture-independent (and thus > non-multilib) files, though unfortunately it is constantly getting > abused for them. (IMHO, any file under /usr/lib on a pure 64-bit system on > a multilib arch (such as x86_64) is a bug, but even systemd now abuses > that directory that way. IMHO, everything that does not need to be > multilibbed into /usr/lib and /usr/lib64 should be either in /usr/share or > in /usr/libexec instead.) > > Kevin Kofler > _______________________________________________ > 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@xxxxxxxxxxxxxxxxxxxxxx > g _______________________________________________ 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
