Re: Sets, subsets, syspkgs, and MK*

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

> All changes should have proper reason for developers or users.
> It could be performance, functionality, readability, or
> silly consistency etc, but your suggestion looks too complicated
> for your purpose and benefits.

I showed complicate use cases because I want to share long term views.

> It looks you put several random idea into one suggestion
> without proper abstraction. That's the reason why many people
> get confused and complain your suggestion.

You seem to expect a perfect suggestion in the first place & oly pointing
out mistakes.  I'm not doing like that.  We are confused because we don't
have any well-defined concept & terminology yet.

> 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. :)

>   USE_foo=no should be used if users want to disable functions
>   in files which are also required by other necessary functionality.
> 
> In this case, you can still apply TNF binary patches into
> your MKfoo=no tree. All things you need are simple, to change all
> bad MKfoo usage (which generate different binaries) to USE_foo
> and adjust distrib/sets/lists files accordingly.
> (we also have to rename MKDYNAMIC and MKCRYPTO_patented etc. though)
> 
> 
> Your second suggestion might be:
> 
>   Put all possibly optional functionalities switched by MKfoo variables
>   into separate module (or similar) files like libc_yp.so mentioned above,
>   to make binary patches also optional per each MKfoo.
> 
> In this case, we should consider if it's really worth to split it
> per each MKfoo functionality. Some of them might be worth,
> but blindly changing all MKfoo functionalities defined in bsd.own.mk
> is quite misplaced order, and many people won't agree with it.
> (we already see it even on functional kernel modules)
> 
> In MKYP case, users who don't use YP don't need bianry patches for YP
> nevertheless his binaries are built with or without MKYP=no,
> i.e. nevertheless his libc contains vulnerable YP functions or not.
> Putting efforts to libc_yp.so which have limited functionality
> would give us fewer benefits, just saving traffic for extra patches.

You don't understand yet.

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

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

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

> 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).

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.

Masao

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