Masao Uebayashi <uebayasi%tombi.co.jp@localhost> writes:
>> 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.
That's right - you'd need to have MKLOGIN :-) But no one has ever wanted
a system without login enough to add a MK variable. So probably there's
a MKBASE=YES for the things that are really required.
> 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.
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.
>> 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")
I don't think that does anything except renaming. MK is HAVE and USE is
USE.
> 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.
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.
Attachment:
pgp6CZOEG6xTD.pgp
Description: PGP signature