Jeremy C. Reed wrote:
> We have numerous GNU_CONFIGURE packages that will just work. (Only some
> are too old to support --mandir.) This is around 2480 packages that will
> work instantly.
> 
> Since we already manually set our ${PREFIX}/man for many packages and
> since the other GNU_CONFIGURE packages will just work, we should allow
> this to be customized.
> 
> I have been using share/man for over a year to build numerous packages. I
> have had to make customizations as I encounter them, but most are just
> modifying the hard-coded ${PREFIX}/man to my ${PREFIX}/${PKGMANDIR}.
> 
> I guess I should set up a bulk build to see how many packages are broken.
> 
> Only a few people have commented on this. A few want it and a couple
> don't.
> 
> As for the issue with added support for new custom variable, it can be
> clearly marked as experimental.

This is one of those types of changes which increases the burden on 
package maintainers, and I still question the value of this new variable 
and the subsequent changes that would be needed in the PLISTs.  As it 
is, I see three scenarios:

(1) LOCALBASE=/usr/pkg.  In this case, pkgsrc uses a completely separate
     man heirarchy than /usr, so nothing needs to be changed.

(2) LOCALBASE=/usr and everything is from pkgsrc.  In this case, pkgsrc
     manages all of /usr, so nothing needs to be changed.

(3) LOCALBASE=/usr and pkgsrc mixes with system-installed files.  This
     is the only case where I could see a desire to install man pages in
     /usr/share/man.  However, we would need to deal with man page naming
     conflicts, which I don't see being addressed in your proposed change
     or your patches.

I don't think the INFO_DIR situation is the same -- there we are 
referring to GNU documentation for a GNU program in a GNU-specific 
directory, so it's easy to just set --infodir=... and have ~everything 
work.  FWIW, I didn't really like that change either for the same 
reasons as I outlined above.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>