URL:
https://github.com/SSSD/sssd/pull/5845
Title: #5845: sss-analyze: Fix self imports
stanislavlevin commented:
"""
Is FHS enough reason?
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#usrlibLibraries...
4.6. /usr/lib : Libraries for programming and packages
4.6.1. Purpose
/usr/lib includes object files and libraries. [21] On some systems, it may also include
internal binaries that are not intended to be executed directly by users or shell scripts.
[22]
Applications may use a single subdirectory under /usr/lib. If an application uses a
subdirectory, all architecture-dependent data exclusively used by the application must be
placed within that subdirectory. [23]
4.7. /usr/libexec : Binaries run by other programs (optional)
4.7.1. Purpose
/usr/libexec includes internal binaries that are not intended to be executed directly by
users or shell scripts. Applications may use a single subdirectory under /usr/libexec.
Applications which use /usr/libexec in this way must not also use /usr/lib to store
internal binaries, though they may use /usr/lib for the other purposes documented here.
Rationale
Some previous versions of this document did not support /usr/libexec, despite it
being standard practice in a number of environments. [26] To accomodate this restriction,
it became common practice to use /usr/lib instead. Either practice is now acceptable, but
each application must choose one way or the other to organize itself.
It *was* and *is* an error to package an executable into Python's site-packages.
I'm trying to understand your objections to this, but can't see, sorry.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/5845#issuecomment-990723195