Ceri Davies writes: > Hmm, no, that's not what I was trying to do. I'm trying to avoid anyone > having a WTF? moment when they find yet another pathname for sendmail in > /usr/lib that it looks like they'll have to do something with.
I think WTF moments are best handled with decent documentation. > I'm specifically trying to make it easy to swap out sendmail, and I > think that for anyone unaware of mailwrapper's presence that ls output such > as the following: > > lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/bin/mailq -> > ../sbin/mailwrapper I think the existing hard links function just fine. As an architectural matter, I don't think that the readlink() contents of symlinks in /usr/bin should be considered to be "documentation" for the system. I understand what you're saying, and that it's an intentional kick in the seat to the admin, but I don't think that's the right way to do this. Why not just make it "../sbin/please-read-the-danged-man-page-already"? > The second gives no clue as to what is going on, while the first should > at least get folk thinking about firing up a manual for mailwrapper. I don't think this is the right way to do it. Update man pages, add new content to docs.sun.com, blog about it, post on netnews, paint skyscrapers, do whatever you want in the way of communication to let folks know about the "right" way to do things. To make it even more obvious, put /usr/lib/sendmail (the wrapper) into a separate package from the actual sendmail delivery. The wrapper could go in SUNWcsu, for instance. But I don't think it's necessary to encode documentation into the symlinks. Even if users do ignore the new documentation, little is lost: those users get exactly what they want, almost as if they'd used the system properly. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
