Subject: mk/defaults/mk.conf (was: Re: Does SETGIDGAME belong into defaults/mk.conf?)
To: None <email@example.com>
From: Roland Illig <rillig@NetBSD.org>
Date: 11/10/2005 01:25:30
Roland Illig wrote:
> the variable SETGIDGAME is used inconsistently. In the NetBSD base
> system SETGIDGAME is used to say whether a package wants to install its
> game binaries as set-gid.
> The appearance in defaults/mk.conf suggests that SETGIDGAME is a
> user-defined variable.
> Declaring a variable as both package-defined and user-defined cannot
> work. What do we want to do about that?
The issue is even worse. There hasn't been a clean definition (or even
documentation) of which variables come from which sources for the last
eight(!) years, that's since pkgsrc has been born.
There are six sources from where variables do affect pkgsrc:
- the package Makefile
- some Makefile.common
- the pkgsrc infrastructure
- the shell environment
- the command line
Most variables have exactly one source where they may be set. Some
others may be set in either mk.conf, the shell environment or the
Because of the similarity of the filename, I have always assumed that
all variables in mk/defaults/mk.conf are default values for things that
can be set by the pkgsrc user in mk.conf. But this is wrong. This file
has become a placeholder for all kinds of variables, lacking proper
comments explaining what each variable is meant for.
Let's split up mk/defaults/mk.conf into pkg.mk (defaults for variables
from the package Makefile and Makefile.common), pkgsrc.mk
(infrastructure defaults) and user.mk (the current mk.conf) to make
clear which variables belong to which category.
I would even go a step further and also define cmdline.mk (with all
variable definitions commented out) for documenting all variables that
are intended for command line use. That way, the pkgsrc.help.mk file
(which I proposed some weeks ago) would make up a really good, quick