I could have sworn I had seen something about this on list in the past month, and didn't have time to answer, but I cannot for the life of me find it. Unfortunately, /usr/libexec is not a part of the current FHS, but, is a part of the 3.0 draft 1 (which hopefully will become official someday).
See: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA and http://www.linuxbase.org/betaspecs/fhs/fhs.html#usrlibLibrariesForProgrammingAndPa Now I bring this up because Apache deliberately using /usr/libexec, and years of avoiding this directory like the plague really irked me. I was gonna complain about it not being compliant, and then I read the FHS draft, where something else caught my eye. The /usr/libexec directory, which is likely to be a part of the standard, allows the use of a sub-directory but does not require it. This reminded me of an old problem with gvfs and policy-kit/u-whatever (IIRC). We should probably make a conscious effort to gradually undo the past 15 years of moving private stuff into /usr/lib/<packagename>, but I'm actually more curious as to the rationale of forcefully separating these items. Would it not be better to let the package maintainer make this decision for us going forward? It might mean making a little bit of a mess in /usr/libexec, but it is one less editor responsibility, and actually might save a patch or two going forward. I have only one specific instance where it has made any difference whatsoever (gvfs), but that debacle was entertaining, despite being annoying. Monkey, football...I think my comments in the patch header way back when reflected as much. :-) Any thoughts? Objections? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
