At Tue, 15 Dec 2009 22:55:44 +0900, Masao Uebayashi
<uebayasi%tombi.co.jp@localhost> wrote:
Subject: Re: Sets, subsets, syspkgs, and MK*
>
> > Sort of.... "NETBSD_CONFIG_HAVE_*" is sort of like "USE_*" and
> > "NETBSD_CONFIG_USE_*" is sort of like "MK*".
> >
> > It might be a useful renaming though -- just from a name-space
> > clarification point of view. And I would stick pretty much with the
> > current meanings and prefixes:
> >
> > NETBSD_CONFIG_MK_* - _build_ (and install) a subset
> > (implying to change "contents")
> >
> > NETBSD_CONFIG_USE_* - enable a feature in a program
> > (implying NO change to "contents")
>
> My point is to realize that most USE_* variables change signature globally.
> USE_YP even changes libc signature.
Ah, yes indeed _some_ USE_* variables do currently change the
distribution contents. I guess we disagree on the relatively quantity
only. I would say that "most" USE_* variables do not change the
distributions contents. Only three out of 10 or 11 of them do so. ;-)
Some (at least one, maybe two) are also poorly named and don't seem to
belong with the ones we're discussing, so that doesn't help clarify
anything either.
As for the "signature" of the distribution, well of course, that's the
whole point of the USE_* variables -- they necessarily change how
various files look on the inside, including libc. That's why they must
be set to one fixed default for all official distributions. You can't
go changing any of them, any more than you can change any of the
Perhaps this is where I've been confused. By "contents" I thought you
meant the list of files in the distribution, not the content of the
files themselves (or both).
BTW, have you considered this comment in share/bsd.own.mk?
# USE_* options which default to "no" and will be forced to "no" if their
# corresponding MK* variable is set to "no".
I suspect if USE_INET6, USE_KERBEROS, and USE_YP were controlled in a
similar way to USE_SKEY (i.e. with the MKINET6, MKKERBEROS, and MKYP
settings forcing the corresponding USE_* value) then their use in
creation of the sets could be eliminated and only the MK* variables
would be used in distrib/sets/sets.subr to control the list of files in
a given distribution.
> No one has answered
> my question - why don't we distribute binary patches?
That's a good question, but of course I don't have a real answer.
I have distributed binary patches privately though, to my client sites,
using "build.sh -Uu" again after applying source fixes and then
selecting those files noted as freshly installed in the $DESTDIR/METALOG
file (my wrapper script for build.sh adds a comment to the end of the
METALOG file after every run to make selecting newly installed files
much easier). I.e. I would do a full build with virgin sources, then
apply the patches and update the build, and then archive up the files
(re)installed by the update. I didn't bother to try to ship only the
necessary binary deltas (i.e. compress the patch), but assuming one has
tools to create and apply such binary deltas on the target systems then
one could also do that level of optimisation as well. One could also
package binary patches up in pkg_install format, but I didn't go that
far either.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpphadLDHfgG.pgp
Description: PGP signature