The mtree and man pages

[Anders F Björklund]

Ryan Schmidt wrote:

>> Stupid, stupid, stupid Reply rules on this list...
>
> The list configuration is not stupid, for the reasons outlined here:
>
> http://www.unicom.com/pw/reply-to-harmful.html

As long as you can live with a few responses not making it to the list,
due to me hitting the wrong key/button then everything is fine with me. 
:-)

> ding that to the configure.pre_args would probably break all the ports 
> whose configure scripts don't recognize the --mandir argument, 
> wouldn't it? I hate MacPorts base changes that break whole swathes of 
> ports. I feel that people should feel free to make such changes to 
> base, so long as they also modify all affected ports so they do not 
> break as a result. If that is too cumbersome, then IMHO the change to 
> base should not be made. For example, making mtree violations fatal 
> errors broke lots of ports. That should not have been done.

Most likely it would break ports not using regular autoconf configure, 
yes.
It mostly works for the %configure macro in RPM, but certainly not 
everywhere.

>>> Some ports that install into ${prefix}/man either use their own 
>>> build system or plain have it hardcoded in their Makefiles. For 
>>> example, MacPorts have hardcoded the location of ${prefix}/share/man 
>>> in doc/Makefile, no matter what ${mandir} is ? The main reason why 
>>> it didn't used to be such a big fuzz, was because of the 
>>> ${prefix}/man -> share/man symlink.
>
> And why is it now a big deal to track these mtree violations? I still 
> have said symlink.

I don't know either, earlier changes were delayed due to 
DarwinPorts->MacPorts,
and now they are being delayed due to man->share/man. Both petty, in my 
book :-P

--anders