tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Sets, subsets, syspkgs, and MK*

> > 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/"
>      92 .endif
> lib/libc/yp/
>       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. 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
> How a patch of is generated?  By enabling *_YP, build, compare
> DESTDIRs, and diff  If we have, *_YP is *not* global.
> *_YP=yes and *_YP=no generates bit identical

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

Home | Main Index | Thread Index | Old Index