Re: Sets, subsets, syspkgs, and MK*

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

> > Probably your first suggestion should be:
> > 
> >   DESTDIR built with MKfoo=no should be subset of MKfoo=yes build.
> >   i.e. MKfoo=no just disable build and installation of files
> >   which are used only for functionality "foo", and
> >   no other existing binary should not be changed.
> 
> You're repeating what I'm saying in your words. :)

I'm saying you also use too extra words so other guys get confuseed.

I'm asking if there is any objection against the words
"MKfoo=no should not produce different binaries but should be subset"?

> You don't understand yet.

Because you don't explain clearly what's the problem?

> *_YP=no users can't apply *any* libc binary patch too.

MKfoo=no users can apply any patches if MKfoo=no always produces subset.
If MKfoo=no doesn't create subset it should be renamed to USE_foo.

USE_foo users can't use binary patches since they are custom binaries.
(Think USE_PCC for example)

What's wrong for your purpose?

> The other option is always build YP functions in libc.  Do you still think
> of this as an effort?

What's problem on this for your primary goal?
This the most simple way to make binary patch works for all users
without complicated method and explanation.

Or "binary patches for all users" are not your goal?
"Making all stuff optional" is your goal?

> Anyway, you'll have no benefits.  Because binary patch is for users.  You're
> obviously not. :)

If once you remove "wrong" MKfoo=no usage,
all users can use binary patches.

Or you are saying all users should be able to use all existing MKfoo=no
varilables *and* binary patches? It looks unlikely for me and
that's the reason why I'm asking what's your primary goal.

Again, what's your goal and what is "benefit" for you?
It looks you often write different purpose in each sentence.

> > Just ask to rename MKfoo into USE_foo for your current primary goal
> > (cleanup set files and reproducible builds, I guess).
> > I don't think it requires so complicated explanation
> > if your primary goal is clear.
> 
> I've already got *strong* objections against *removing* existing MK* / USE*
> vars (although I've never said I'd remove those).

Could you post actual URLs of those messages?

> I think of existing vars as user visible API.  I don't think changing them
> is going to happen.  Worse their use has some mistakes / exceptions.  That's
> why I'm proposing a new namespace.  This is a migration.  Existing old
> vars will be gracefully handled in bsd.own.mk.

You still mix another idea again here.
Please mention only your *primary goal* first.

ABI should be kept for backword compatibility, but
API for source build can be changed if your primary goal
is reasonable and worthful enough. You can just notice it
in current-users and doc/UPDATING.
---
Izumi Tsutsui