At Wed, 16 Dec 2009 13:04:46 +0900, Masao Uebayashi
<uebayasi%tombi.co.jp@localhost> wrote:
Subject: Re: Sets, subsets, syspkgs, and MK*
>
> > 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.
>
> I've not investigated all those vars. I think the basic rule is that
> bsd.own.mk
> is the place to sanitize those vars given by users.
Yes, the part of bsd.own.mk to which the comment applies does indeed
sanitize the appropriate USE_* options based on the state of the related
MK* options.
I think the initial fix to get rid of the use of the USE_* variables in
the distrib/sets infrastructure would be simply an extension of this
sanitization. Plus of course the Makefiles which are controlled by
these various options also have to be corrected to use MK* where
appropriate and to only pass USE_* to the preprocessor/compiler.
Once this "fix" has been done to properly separate the meaning of USE_*
and MK* then perhaps our discussion about configuration management of
patches won't be additionally confused by their current intertwined
state. :-)
I could offer a patch which cleans this up in the way I've suggested,
but perhaps it would better be done directly by a committer who is
already very experienced with the whole build system. I have a couple
of other patches in my current "-current" working tree that would be
difficult to work around to produce a clean patch without using the
likes of Git or Bazaar or Darcs (or maybe Monotone).
If someone would like me to show my suggestions as patches though, I
could take the time to prepare them on a relatively clean tree, though
I'm not sure I have the time and resources currently to do a full build
and test of all the sane option values (though my values do differ from
the defaults so I would at least test one combination).
> Some vars have dependencies, some have conflictions, and some only change
> signatures of subsets. Pretty much same seen in any packaging systems.
> Difference is we have more control of our own basesystems.
I think though the point is that all of these variables are, and should
be, invisible to any release engineering where what we're doing is to
update a given release with fixes and then provide binary patches for
those fixes.
So, I don't think it matters that the USE_* variables change the
signatures of the subsets, or that the MK* variables change the very
list of files contained in the subsets. These settings must necessarily
remain static throughout the release management of a given release
branch. And of course anyone who changes these variables from their
default settings must create their own distributions and all their own
patches since neither the signatures of their subsets, nor even the
list of files in their subsets, are likely to match those produced
officially by the core project (i.e. TNF), and they must not expect to
be able to make use of any subsets or patches from TNF. They must rely
on source patches alone.
Yes, perhaps in an ideal world TNF would produce distributions and
patches for every sane combination and permutation of every USE_* and
MK* setting possible, but for now that would be a blue-sky dream.
I for one wouldn't even make use of TNF-produced distributions or
patches, even if they ideally matched my USE_* and MK* configurations.
I would still want to build everything I use from my own source trees,
in part because I will probably always also apply my own source changes
to the official TNF sources, so again my products will be unique
regardless of whether I change any USE_* and/or MK* values or not.
> You seem to be the only *serious* NetBSD user in this thread. :)
I have made serious use of NetBSD over the years, to be sure! :-)
> I think your use of METALOG (check only updated & installed files) makes much
> sense.
I felt it was a bit of a hack at the time.
However in some sense it is a very natural way to extract, from the
recursive build system we use, a list of modified/updated product files
after some change has been made to the sources.
> I feel unnecessarily rebuit files & installed files annoying. If we compare
> DESTDIRs by content, timestamps don't really matter... but still confusing.
Indeed, the way I have used METALOG does rely on the build being as
optimal as possible -- at least it does to the extent that one wishes to
create the most optimal patches possible.
There are some things that are not captured so easily in the METALOG,
such as install kernels and such, and even some things which are
captured require additional support from a patch installation tool, such
as boot file changes, etc. which would then have to be installed on each
target system, first to the /usr/mdec files, then to the boot partition(s).
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpqJmvNboA6v.pgp
Description: PGP signature