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@xxxxxxxxxx> 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: >> >> http://pathname.com/fhs/pub/fhs-2.3.html#PURPOSE22 >> >> """ >> 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 > 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. [23] > > Ok, found a cached version of FHS-3: http://webcache.googleusercontent.com/search?q=cache:GIn-hmSAjL0J:dev.linuxfoundation.org/~licquia/fhs-3.0-drafts/fhs.txt+site:http://dev.linuxfoundation.org/%257Elicquia/fhs-3.0-drafts/&hl=en&strip=1 4.6. /usr/lib : Libraries for programming and packages 4.6.1. Purpose /usr/lib includes object files and libraries. ^[22] On some systems, it may also include internal binaries that are not intended to be executed directly by users or shell scripts. ^[23] 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. ^[24] 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. ^[25] ^[26] 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. ^[27] 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
