Re: Sets, subsets, syspkgs, and MK*

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

> The rest of the world has just one distribution.  For binary updates,
> all MK/USE should be in their default states.
> 
> If you want login to work w/o kerberos and with, you need loadable
> modules to have the checks, and you end up with pam.

Agreed.  I've come to realize PAM is the way to go.  But its strength is
half hidden now we don't distribute binary update.

> I don't think that does anything except renaming.  MK is HAVE and USE is
> USE.

There's some exceptions like MKSOFTFLOAT.  I think migrating to a new namespace
is worth doing.

> Yes, except that a build
> 
>   HAVE_FOO=no
>   USE_FOO=yes
> 
> will fail.  That's the basic problem - the notion of binary subset
> builds is inconsistent with key utilities using optional components.
> 
> If you are willing to put kerberos libs and utils in base, and have the
> sets be about omitting compiler etc., this can work.  As it gets finer
> grained, it gets hard.

Those knowledge should be concentrated in one place (== bsd.own.mk).  We need
to check a given configuration only once when the user kicks build.sh.  Because
those configuration variables don't change during build's lifecycle.  By 
generating
a static (== no .if) netbsd_config.mk, it gets clearer that those variables are
constant.

Masao

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