Re: Sets, subsets, syspkgs, and MK*

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

> > Could you show exact example of usage how global patches
> > and partial patches can be generated by MK* variable settings?
> > Users can still choose necessary patches from global one as cube says,
> > unless builders blindly generate patches from whole two sets of DESTDIR.
> 
> I see you have a solid view how to generate binary patches.

You too, don't you?

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.

> > > If you create a binary patch of YP code in libc, how do you call it?
> > 
> > It's better to mention how "a binary patch of YP code in libc"
> > can or cannot be generated by MK_* or USE_* variable in your idea.
> 
> Problem here is, I can't apply "YP code in libc" patch if I disable *_YP.
> I can't apply any libc patch if TNF decides to enable *_YP by default.
> Because YP code in libc is contionally built:
> 
> lib/libc/Makefile:
>      90 .if (${MKYP} != "no")
>      91 .include "${.CURDIR}/yp/Makefile.inc"
>      92 .endif
> 
> lib/libc/yp/Makefile.inc:
>       6 SRCS+=  xdryp.c yp_all.c yp_first.c yp_maplist.c yp_master.c 
> yp_match.c \
>       7         yp_order.c yplib.c yperr_string.c ypprot_err.c
> 
> And end up with different signatures by *_YP.  If we move YP code out of libc
> (e.g. libc_yp.so) and lazily load (dlopen()) it, the main libc is never
> affected by *_YP.  Meaning *_YP only changes subsets.  Meaning I'm 100% sure
> that I'm not involved by a YP bug, because I don't install libc_yp.so.
> 
> How a patch of libc_yp.so is generated?  By enabling *_YP, build, compare
> DESTDIRs, and diff libc_yp.so.  If we have libc_yp.so, *_YP is *not* global.
> *_YP=yes and *_YP=no generates bit identical libc.so.

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.

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

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.
---
Izumi Tsutsui