harald.hoyer at gmail.com
Thu Oct 27 08:46:29 UTC 2011
On 10/27/2011 10:34 AM, Harald Hoyer wrote:
> On 10/26/2011 06:21 PM, Toshio Kuratomi wrote:
>> On Wed, Oct 26, 2011 at 03:18:42PM +0200, Harald Hoyer wrote:
>>> On 10/26/2011 03:07 PM, Chris Adams wrote:
>>>> Once upon a time, Richard W.M. Jones<rjones at redhat.com> said:
>>>>> Having said that, the split between /sbin and /bin is not a truly
>>>>> historical one, ie. it didn't exist in V7. I think it was added by
>>>>> System V which did a lot of other strange stuff too.
>>>> Well, historically, a bunch of system utilities were in odd places like
>>>> /etc and /usr/lib. The idea of /sbin and /usr/sbin was to get compiled
>>>> executables out of those places (and to not clutter up the "normal" bin
>>>> directories with stuff users didn't need).
>>> For daemons, which should not be called directly on the command line, I
>>> would suggest to move them to /usr/lib/<packagename>/ anyway.
>> In context, at least, this is wrong advice as it's a violation of the
>> /usr/lib includes object files, libraries, and internal binaries that are
>> not intended to be executed directly by users or shell scripts.
>> Specific Options
>> For historical reasons, /usr/lib/sendmail must be a symbolic link to
>> /usr/sbin/sendmail if the latter exists.
>> The daemons and such were in places like /usr/lib to begin with. This was
>> deemed to be the wrong place for them. Instead they were placed into
>> You may be quibbling over the use of "shell scripts" in that section
>> as you
>> might think that daemons aren't run from shell scripts in systemd and
>> illustrates that shell scripts were only an implementation detail in
>> In doing so, however, you miss out on "internal binaries". A daemon
>> executable is the public entry point into a service so they aren't
> And I want to point to
> http://pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1394 , which you omitted:
> 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. 
Ok, found a cached version of FHS-3:
4.6. /usr/lib : Libraries for programming and packages
/usr/lib includes object files and libraries. ^ On some systems, it
may also include internal binaries that are not intended to be executed
directly by users or shell scripts. ^
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
4.6.2. Specific Options
For historical reasons, /usr/lib/sendmail must be a symbolic link which
resolves to the sendmail-compatible command provided by the system's
mail transfer agent, if the latter exists. ^ ^
4.7. /usr/libexec : Binaries run by other programs (optional)
/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.
Some previous versions of this document did not support /usr/libexec,
despite it being standard practice in a number of environments. ^ 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.
More information about the devel