Re: Sets, subsets, syspkgs, and MK*

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

>   | I'm asking if there is any objection against the words
>   | "MKfoo=no should not produce different binaries but should be subset"?
> 
> If you're asking if Masao Uebayashi agrees with that restatement,
> then clearly I cannot comment.
> 
> If you're asking whether anyone would object to that, then yes, I would,
> both because it doesn't provide what I really want, and because it doesn't
> work anyway.

Hmm, what do you really want?
Removing whole "foo" functionality even if it will produce
different binaries which can't use binary patches?
If you are saying it's also okay for your purpose, that's fine.

>   | USE_foo users can't use binary patches since they are custom binaries.
> 
> But MKfoo=no must imply USEfoo=no, surely - you cannot possibly be
> planning on using something that you don't build.

Ah, okay, maybe that's the reason why new variables are proposed.
(though I'm not sure if they are really wroth)

> That is, I see three different setups:
> 
> foo is built, installed, and used
> foo is built (by TNF perhaps) but not installed (and hence not used)
> foo is not built at all (and even if built and installed later, never used).
> 
> Set (3) there is me.  I don't see this to being a problem for binary
> patches though, which are for people in the first two sets.  Just forget
> about anything related to how you deal with troglodytes like me, and
> make it work for people who prefer using binary releases & updates.

Probably he proposes the way to make the third one of above could
also be a subset of the standard build like the second one by putting
possible optional stuff into moudles so that binary patches work.

On the other hand, actual users of the third one including you
are saying that they don't need binary patches, but he still says
all users including ones who are using third one should be able
to use binary patches? I'm not sure how many NetBSD users who
want custom environment also want standard TNF binary patches..

I don't see his primary goal yet so I can't comment about his proposal
properly, but it looks less benefits (making binary patches more common?)
than its cost (complicated variables, conditionals, and module files?).
---
Izumi Tsutsui