Subject: mk/defaults/mk.conf (was: Re: Does SETGIDGAME belong into defaults/mk.conf?)
To: None <tech-pkg@netbsd.org>
From: Roland Illig <rillig@NetBSD.org>
List: tech-pkg
Date: 11/10/2005 01:25:30
Roland Illig wrote:
> Hi,
> 
> 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
- mk.conf
- 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 
command line.

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 
online help.

Roland