On Sun, Nov 05, 2006 at 06:55:23PM +0100, Roland Illig wrote:
> Joerg Sonnenberger wrote:
> >I don't like it. IMO this can be considered a recursive dependency as it
> >won't help when creating a new package or updating one with changing
> >directory list.
> 
> That may be the case for _some_ packages. Assuming that most packages 
> only have "bin" and "man/*" in that list, they will usually find these 
> directories precreated when the packages are installed for the first 
> time, with an empty PLIST.

No, they will not. Installation to /usr/pkg will die (sooner than later)
and with it mtree. No automatically precreated directory structure under
the installation PREFIX.

> Another effect is that an error message is printed whenever something 
> that should be a directory already exists as a file. Before, one had to 
> wait until the check-files target caught that error. Now, the error 
> message is as clear as possible.

See above -- will not work for changing directory list.

> >The list of entries in INSTALLATION_DIRS is typically
> >short enough as well, so the new variable is often even longer...
> 
> It depends. I had been annoyed by writing ${PKGMANDIR}/man1 instead of 
> man/man1, for example. That is converted automatically now.

.oO(who introduced PKGMANDIR again)

> 
> Another benefit is that many packages will only need the same definition 
> (INSTALLATION_DIRS_FROM_PLIST=yes) instead of slightly different ones 
> (INSTALLATION_DIRS=...).

Many packages don't need it at all. Those which do normally use them for
documentation or example directories. Does that mean we add a magical
install, which creates the missing components in the target name?

> Using this variable, it is also possible to eliminate many of the 
> ${INSTALL_*_DIR} commands in self-written do-install targets. Taking all 
> these reasons into account, it felt quite good to me.

And this could have been replaced with INSTALLATION_DIRS already. This
is not new for that reason.

Joerg