Perry (?) recently fixed a long-standing buglet and moved rmail from
/bin/rmail to /usr/libexec/rmail.  This is a Good Thing, in that it
makes rmail dynamically linked and moves it out of the root fileystem
(my root filesystems are increasingly full or overfull due to growth
of the static libc.)

rmail is a problem child: it's used for UUCP, and UUCP systems stil
embed the pathname "/bin/rmail" in uux/uuxqt scripts as part of the
UUCP e-mail transport mechanism.  To avoid breaking e-mail from UUCP
peers that hardcode /bin/rmail, Perry introduced a symlnk 

/bin/rmail -> /usr/libexec/rmail

/usr/share/mk/{lib,prog}.bsd.mk (and possibly others) now have support
for  a SYMLINKS=  Make variable, which creates  symlinks between files.


I've found SYMLINKS loses when doing a build with DESTDIR non-null.
If DESTDIR is /foo/bar,   then bsd.prog.mk  creates a symlink

	/foo/bar/bin/rmail -> /foo/bar/usr/libexec/rmail

which is clearly not going to work when someone uses the contents
of /foo/bar to create distribution tarballs.

I thought there was a simple fix in this case: just mandate that
the link be  one of
	/bin/rmail -> /usr/libexec/rmail
	/bin/rmail -> ../usr/libexec/rmail

Either one works for this simple case -- someone who moves /bin around
in their tree is going to lose in so many other ways that there's
little to choose between the two.  I mildly prefer the second because
it works consistently  in a build tree, without  having to chroot
there.    I'm told Charles Hannum has come down strongly in favour
of the first alternative, since it avoids lossage for those who
use symlinks or automounters to manipulate their filesystem namespace;
and Chris Demtriou has just advocated the second alternative.

I haven't sent a PR because I don't know what the right solution is.
Maybe some special-case pathname processing in uuxqt is the right fix
for UUCP; but now we have SYMLINK= support in the tree, IMHO it should
either work, or be removed.

Anway, this looks like the right place to discuss it...