Re: Sets, subsets, syspkgs, and MK*

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

    Date:        Thu, 17 Dec 2009 01:16:29 +0900
    From:        Masao Uebayashi <uebayasi%tombi.co.jp@localhost>
    Message-ID:  <20091216161629.GF19136%x300.tombi.co.jp@localhost>

  | You keep assuming I want to build from source.  The opposite.

No, I don't assume that at all - what I (more than just I, I think)
have been assuming is that you want to supply binary patches to people
with non-standard netbsd builds (or installs).   That's what makes no sense.

  | No one explains *WHY* YP code in libc has to be conditionally built.
  | Who'll explain that?

That isn't the question you really want to ask, I think - so if anyone
does explain, you won't like the answer, because they won't be answering
what you really want to know.

What you want to know, I think, is why the YP code needs to be a fundamental
part of libc, rather than being a separate entity (that can be used, or
not used).

But to answer your actual question first, it is because some people
don't like YP, and want to remove it, but others need it, so it cannot
simply be blasted into orbit - conditional compilation is the way that
both sets of needs are satisfied.

The code is the way it is, I assume, as it all started well before we
had any dynamic libraries, YP predates that (in BSD, and perhaps even
in SunOS).   Then, having a library just dynamically link in another
library if it was wanted (or fail to link it if it wasn't present) just
wants functionality that existed.

To take this one step further, even if you achieve your aim, and have the
YP code separated out as a module, the USEYP variable will still need to
go change the libc signature, because people like me would want to make
sure that libc can never load the YP nonsense, no matter what libraries
happen to be installed, so there will still be conditional compilation in
libc, and just like now, binary distributions (and binary patches) will
support only the TNF accepted settings of those config options, anyone
who wants different uses source.

For the question you really want answered, there is no particular reason
beyond history I suspect.   If it were up to me (which it isn't), the YP
code wouldn't exist at all (I'd simply remove all of it, and everything
related to it).   Of course, for this, the YP case is just one instance,
and others might not nearly be so clear cut (IMO).

(YP users, there is no need to reply and say that you need it kept, there
is no serious proposal to remove YP from NetBSD - not even from me...)

What I'd suggest that you do is look at David Brownlee's message, and 
simplify your request - not what you want, but the way you're asking
for it - it is all getting very confused.

Take the various MK* and USE* options, one by one, look at each of those,
and where they affect anything that seems like as if it might create problems,
suggest moving the functionality from being a core part of libc to being
an external module that is linked when needed.   There's no need to even
mention the system config options (MK* and USE*), and probably not even a
reason to mention binary packages (and perhaps not even syspkgs, though they
give something of a rationale for making more smaller modulas).

You won't make the libc signature changes go away that way, but you can
make those changes needed by a smaller set of people, and so binary releases
and patches more useful to a larger set.

Not everything will be accepted to be changed (I assume, or guess), so
start with the most likely ones (like YP) so people can get used to the
idea - I suspect you'll find a fair bit of support for anything that
seems to be moving YP further (and further, and further...) away from
core NetBSD, so it is more obviously an option for just those who need it.

Once that one is done, then you can propose the next, where you'll have
the advantage that people will have seen what you're actually proposing
to do, and have reports that things really do still work, and so you're
less likely to get defensive objections "that sounds risky, don't do it"
to later proposals.

kre