FC more FHS clashes (was: BIND and FHS)

[Jeff Spaleta]

On 3/6/06, Chris Adams <cmadams at hiwaay.net> wrote:
> Does FHS say /usr/lib/sendmail should just exist or that it should be
> used _instead of_ /usr/sbin/sendmail?
Friendly advice.. it helps to read up on reference material before
asking questions... or else you run the risk of having your questions
summarily disregarded.

In this case... /usr/lib/sendmail is a symlink specifically required
for historical reasons but there is no requirement that any modern
application use it as the prefered location. In fact the fhs 2.3 goes
out of its way to explain that /usr/sbin/ is the current default and
there is an expectation that applications will be using the default
/usr/sbin/sendmail location if possible. I belive the referenced
footnote clarifies this.

Just so everyone in this discussion has a clear understanding of the
text in question, I will quote 
http://www.pathname.com/fhs/pub/fhs-2.3.html. It would have been
helpful if the original poster would have provided a quote and
citation of the fhs they felt was in conflict. I don't see an issue
according to the the 2.3 fhs and I believe the original poster in this
thread has misunderstood the fhs text.  /usr/lib/sendmail must be
provided for "historical reasons" and applications are encouraged to
use /usr/sbin/sendmail which is the current default.

-jef
<quote http://www.pathname.com/fhs/pub/fhs-2.3.html>
Chapter 4. The /usr Hierarchy
...
Specific Options
For historical reasons, /usr/lib/sendmail must be a symbolic link to
/usr/sbin/sendmail if the latter exists. [24]
	
.....
[24] Some executable commands such as makewhatis and sendmail have
also been traditionally placed in /usr/lib. makewhatis is an internal
binary and must be placed in a binary directory; users access only
catman. Newer sendmail binaries are now placed by default in
/usr/sbin. Additionally, systems using a sendmail-compatible mail
transfer agent must provide /usr/sbin/sendmail as a symbolic link to
the appropriate executable.
</quote>