Re: Sets, subsets, syspkgs, and MK*

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 16 Dec 2009 12:28:38 +0900
    From:        Masao Uebayashi <uebayasi%tombi.co.jp@localhost>
    Message-ID:  <20091216032838.GK172%x300.tombi.co.jp@localhost>

  | Problem here is, I can't apply "YP code in libc" patch if I disable *_YP.

If you disable YP (and NetBSD has it enabled) then you don't want to
apply binary patches from NetBSD - you're doing source builds already,
and you want source patches.   Trying to impose binary patches onto
source built systems would be lunacy,

  | I can't apply any libc patch if TNF decides to enable *_YP by default.

I think you're thinking of those things as variables, that can change
at random - they're not, they're constants (for a port/release combination).
Once values are selected (as far as the standard distribution goes) they're
fixed for all time for that release/port, and will never be changed (for
TNF releases, the variables may as well all be deleted, and the code just
selected, or deleted, as appropriate).   The MK* and USE* vars remain in
the sources for others who want to build different releases - but TNF
binary patches are irrelevant to them, they make their own.

In another message ... uebayasi%tombi.co.jp@localhost said (after quoting Greg 
Woods, I 
think)
  | > Folks who create their own binary distributions MUST also create their
  | > own binary patches if they so wish.

  | True.  But it's better their own binary patches are bit identical to the
  | officially distributed ones.  You can doubly make sure. 

Only if their build was identical to TNF's build in the first place.   I
know mine isn't - I deliberately want my binaries to be all just a little
different from the TNF release versions (doing the exact same task, but
with code at a different location, or order, or ...)   If this has no
other advantages, it at least means that someone figuring out a binary patch
attack needs to build one specific for my system, they can't experiment on
their own (or someone else's) and then expect the hack to work without
changes on my systems (this is a kind of pathetic "security by obscurity"
but it is remarkably effective against mass system attacks - worms and such).

Because of that exact reason, no binary patch from TNF (nor anything that
is bit identical) can possibly be useful to me.   They also could not be
useful to anyone who has changed any of the MK* or USE* config settings, for
whatever reason.

Sure, you're right, if you factor pieces of libc, and other things, into
small tiny files, then binary patches can target exactly what is needed
rather than just one big monolithic hunk, but I'm not sure that the MK*
(or USE*) variables are in any particularly relevant way related to what
would be good to move out to separate chunks - perhaps ideally every single
source file that currently go to make up libc should be made into a
separate shared lib, that is linked into the application only when needed.
Or then again, perhaps not...

kre