On Aug 14, 2007, at 02:24, Anders F Björklund 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
Forwarded message: (from me)
Boey Maun Suang wrote:
In addition, it's not much trouble at all to make a port install
man pages into ${prefix}/share/man; in most cases, we either pass
--mandir=${prefix}/share/man to configure or copy it ourselves.
(I suspect that most of the ports that install man pages into $
{prefix}/man are using configure script generated by autoconf <
2.59c, as it was only at that revision that it changed its
default mandir to ${prefix}/share/man.) Consequently, I think we
should stick with installing man pages into ${prefix}/share/man.
Seems very redundant to have that --mandir in each and every
little Portfile. Might as well have the definition next to the
default --prefix=${prefix}, so that it would automatically add --
mandir=${prefix}/share/man --infodir=${prefix}/share/info ? Since
that is now the mandatory location, might as well make it the
default configure arguments as well...
Adding 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.
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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
