[ On Wednesday, November 5, 2003 at 12:40:55 (-0800), Greywolf wrote: ]
> Subject: Re: checkflist error codes
>
> Thus spake Frederick Bruckman ("FB> ") sometime Today...
> 
> FB> Well, since we don't support making sets with non-default options,
> FB> there doesn't seem to be much point at all in running checkflist. Nor
> FB> would it make much sense to try to support building custom sets, as
> FB> sysinstall wouldn't know how to deal with them.
> 
> What, sysinstall runs off the checkflist stuff, too?  Or is it just static
> and not knowing how to deal with anything more than what we tell it?
> 
> I didn't think I was all that far off base with my request; guess I
> was.  Sorry.

I don't think you're far off at all.

I build custom releases with options that affect the sets/lists, and I
happily use "sysinst" to install the results (what's "sysinstall"?).

I currently do keep my sets/lists/* files up-to-date to reflect the
systems I build, but that's only because there's no better and easier
way to make sure that the binary/sets/*.tgz files contain what I build.

One could just tar up all of $DESTDIR into base.tgz and create "empty"
*.tgz files for the other sets files and 'sysinst' would be none the
wiser and just as happy without needing any modification itself, though
modifying the list of binary/sets files 'sysinst' expects is quite
trivial and 'sysinst' has no knowledge of what's actually in those files
(only some rather generic expectations :-).

However the better long-term answer is to embed the package
identification and dependency information right into the build process
for each component file such that the METALOG file ultimately contains
the information necessary to select which files go into which
binary/*.tgz files (and do away with all the redundant information in
the distrib/sets/lists files).  This makes it possible to adjust
compile-time options that affect which products are built (e.g. MKYP,
NO_SENDMAIL, etc.) and still have releases created without need for any
mucking around anywhere else.  Doing it this way also has the advantage
of being able to cleanly and easily support building of old-fashioned
base, comp, misc, man, and etc sets while also being able to create much
finer-grained packages without all the horrible ugly hacks that can
currently be found in distrib/syspkg.

-- 
						Greg A. Woods

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