[ On Sunday, February 23, 2003 at 10:25:52 (-0800), Jason R Thorpe wrote: ]
> Subject: Re: any interest in fully supporting MKYP=no for releases?
>
> On Sun, Feb 23, 2003 at 01:14:27PM -0500, Greg A. Woods wrote:
> 
>  > Since the last time I did this I've been wondering if maybe there's
>  > enough interest in fully supporting these options and maybe some other
>  > similar ones in the base NetBSD sources to make it worth my while to fix
>  > submit patches to the release sets generation procedures (and the same
>  > for generating the obsolete lists) to at least semi-automatically take
>  > them into account.
> 
> If you encounter problems, please submit patches that fix them.

I haven't had any problems so far in the actual build.  If everything
this time mirrors my previous experience then I expect all the resulting
programs to work well too.

Of course I can't bundle the release sets without doing something to the
set list files.  One simple hack that's slightly better than just
applying the checkflist diffs and forgetting about these being options
is to just make sure all the optional files are tagged with appropriate
per-option-unique category names in the second field and then use awk or
such to remove them from the final sets list(s) and add them to the
corresponding obsolete lists.  Another possibility would be to split all
the files for each option into separate lists.

Oh how much easier this release bundling would be if we used a simple
top-down single-pass build system like Jam instead of recursive make! ;-)
The separate maintenance of lists of installed files would be totally
unecessary -- each makefile would simply declare what set each of its
products belonged to and the full dependency tree would include the
final .tgz files and the commands to build them would use the
accumulated product pathnames directly from a macro expansion (probably
with some new built-in xargs type of facility).

>  (Of course,
> the right way to fix the set generation problem is syspkgs...)

Well, possibly, but I don't think syspkgs really solve the problem
properly and easily for build options like these, at least not with the
existing package management tools.  With some of these wide-reaching
build options some files have to be replaced when the option is added.
We currently don't have a proper way to transfer ownership of a file
from one package to another and to squirrel away copies of original
files that would have to be re-installed if the add-on option were
removed.

Also the interplay between some of these options is also almost
impossible to manage from an add-on package point of view.  Each option
cannot just be "added" one by one.  Each combination of some sets of
these options currently creates a unique libc, and as always with static
linking there will lots of other unique files for each combination too.
I.e. with the existing package management tools each combination of
options has to be treated as a lone unique package that conflicts with
any similar package built with any different set of options.

I think the only sane thing to do for now is to build a whole release
for each combination of options and then when you "upgrade" to a
different combination of options the right files can be obsoleted to
truly get rid of all vestiges of the unwanted options.

(Oh, and I forgot to mention eliminating the integrated csh and OpenSSH
stuff too, as well as replacing GNU awk and the GNU grep family! :-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>