UsrMove feature

Harald Hoyer harald.hoyer at
Thu Oct 27 08:34:45 UTC 2011

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>   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 FHS:
> """
> Purpose
> /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 /sbin.
> 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 that
> illustrates that shell scripts were only an implementation detail in sysv.
> 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 internal.
> -Toshio

And I want to point to , 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. [23]

More information about the devel mailing list