Re: Sets, subsets, syspkgs, and MK*

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

> I am not 100% clear on this, but I've always thought that
> 
>   MK*: controls building/installing some group of programs/files
> 
>   USE*: controls whether other programs will try to use a feature
> 
> 
> There are both USE_KERBEROS and MKKERBEROS.  MKKERBEROS removes libkrb,
> kinit, etc.  And USE_KERBEROS removes kerberos support from login etc -
> but those programs are still built.  MKKERBEROS==no forces USE_KERBEROS
> no, since linking against libraries that aren't built with headers that
> aren't installed of course doesn't work.

The use of *KERBEROS variables would be a good starting point.  As you
explained, files are conditionally installed and/or those contents change
too.

My point is to clarify

a) what variable (condition) changes installed files ("subsets")
b) what variable (condition) changes file contents ("contents")

For example, usr.bin/login is conditionally built by USE_KERBEROS / USE_PAM
/ USE_SKEY.  It is always installed.  So it doesn't belong to the "subsets"
I'm saying.

Such a technique is very common & OK for source distribution.  If you build
your image by yourself, you'll get a consistent image.

But we're moving toward modularity.  Yes?  No?  I'm not sure all people have
agreed, but no one has strongly opposed.  Modularity means binary compatibility.
It's like any commercial OS and any other mature OSes.  You install binary
installation & get binary updates (patches).  Everyone runs the identical image.

So now think a bug is found in login(1), and TNF releases a binary update
for it.  But how the official login(1) binary is compiled?  Does the binary
update usable for you?  TNF will distribute only one image for each ports.
Otherwise TNF has to build all the combination of (USE_KERBEROS, USE_PAM,
USE_SKEY) of login(1).  That's unlikely to happen.  If TNF decide to compile
login(1) with all USE_* enabled.  Which means all users who wants to use
login(1) are forced to install Kerberos too.  This is not a good thing.

> I think your notion of subsets matching MK* is very sensible.  There
> will be things that really can't be omitted in a build, but that doesn't
> mean it's totally silly to have a MK* to go along with them.

Unfortunately MK* vs. USE_* usages are a little too confused now.  I'd propose
two variables for now to clearly distinguish "subsets" / "contents" (or
whatever better words):

        NETBSD_CONFIG_HAVE_*    - include a subset
        NETBSD_CONFIG_USE_*     - enable a feature (implying to change 
"contents")

Assume our build is reproducible; if you build twice using the same condition,
you get the identical output.  If you build with NETBSD_CONFIG_HAVE_FOO=yes and 
=no.
You get extra files for =yes.  If the rest files are identical,
NETBSD_CONFIG_HAVE_FOO is (a switch of) a subset.

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635