On Mon, 7 Feb 2000, David Maxwell wrote:

> > > > IMO, it looks better to go with the highest level of abstraction,
> > > > INSTALL_DATA_DIR or INSTALL_MAN_DIR, but it's not like you could
> > > > usefully override this particular one to set a policy, since many
> > > > packages do "mkdir -p ${PREFIX}/man/man1" in their own makefile.
> > All I meant was, you can't set a system wide policy by setting
> > SHAREGRP, for example, as even if the pkgsrc Makefiles consistently
> > used "INSTALL_DATA_DIR" rather than "${MKDIR} ...", many packages
> > would still violate the intention by creating their own directories.
> > Therefore, it really doesn't matter.
> 
> Sorry, I thought I understood, but now I'm confused. You said use the 
> highest level abstraction (INSTALL_), but then said it doesn't matter?
> Certainly we don't want to fix every package in the open source world,
> but if we have 'standards' we aim for, we know what we want, and if
> a pkg breaks something (and causes a problem) we can justify creating
> a patches/* entry to fix it.

Myself, I prefer INSTALL_DATA_DIR and friends over MKDIR on principle,
with the caveat that I wouldn't have mentioned it if you hadn't asked.
For the purpose of setting policy, it wouldn't be useful to anyone
without additional work, and it's certainly not anything I care to
argue about. I'm sorry you brought it up. :-)

I believe the problem Alistair referred to arises with bsd make
packages, where definitions in the package Makefiles (like MANPAGES,
CATPAGES, MANINSTALL) interact with /usr/share/mk/bsd.{own,man}.mk.
The only INSTALL_ definition in the bsd makefiles is INSTALL_INFO
though (which doesn't have a counterpart in bsd.pkg.mk), so unless I'm
missing something, all other INSTALL_ macros should be safe to use.