Traditionally, mh binaries have gone in /usr/lib/mh or /usr/bin/mh. All other distros I am aware of do this as well. The reasoning has to do with the history behind mh (and nmh) more than anything else, in particular how it is meant to be used.
Problem with making this change is that it breaks the FHS. Is there any reason why we *need* this fix, other than tradition?
Actually, it need not break the FHS. The "other" traditional location of mh programs is /usr/lib/mh, and /usr/lib/<package> is OK according to the FHS for binaries for a program that aren't meant to be run by a user. Let me check here a moment. OK. Not *all* of the mh programs go in /usr/lib/mh, just some of them - (from a RedHat machine): /usr/lib/nmh/ap /usr/lib/nmh/conflict /usr/lib/nmh/dp /usr/lib/nmh/fmtdump /usr/lib/nmh/install-mh /usr/lib/nmh/mhl /usr/lib/nmh/mhtest /usr/lib/nmh/post /usr/lib/nmh/rcvdist /usr/lib/nmh/rcvpack /usr/lib/nmh/rcvstore /usr/lib/nmh/rcvtty /usr/lib/nmh/slocal /usr/lib/nmh/spost Additionally, Debian also places: /usr/lib/mh/components which Redhat places in /etc/nmh/components /usr/lib/mh/replcomps which RedHat places in /etc/nmh/replcomps As far as I can tell, replcomps and components both *do* go in /etc/nmh Anyway. I'll check later if the files in the Gentoo build go where they should (/etc/nmh and /usr/lib/nmh being different from normal locations) Additionally, I can prepare a patch/new ebuild that places things in the correct locations.
I don't use nmh anymore so I don't care about this bug. Closing.
