On Mon, 7 Feb 2000, Thomas Klausner wrote:

> What do we do with packages that need some variable set in
> /etc/mk.conf, but which shouldn't have a default for it?

> I think the only problem is that they may break in bulk builds,

> I don't think that setting them to IS_INTERACTIVE is the right way to
> handle that case.

Don't they currently just die, so a bulk build goes on to the next packge?
That seems like proper behaviour to me, as long as they print a useful
error message.  I agree that it seems more friendly than reverting to
INTERACTIVE, which I thought was supposed to be for configure scripts that
just couldn't be fooled, and not for any deficiencies of our _own_ system.  
At least, it fits better with the way I build things ('make install >
makeout 2>&1 &')

I don't think this is the ``only'' problem with these variables. :)

In general, I've found build-time variables to be a royal pain.  They are
a lot _less_ of a pain if they are meticulously documented.  I see quite a
few are documented in mk/mk.conf.example, and README ref's this file.  
That looks good enough to me, so long as pkg commiters are _religiously
updating_ mk.conf.example every time they commit a package with pesky
options.  We are, aren't we?  I didn't notice any conspicuous omissions.

Do you think variables that are ``required'' or ``adviseable'' for bulk
builds should be somehow separated from options like ISPELL_EXTRA_DICT, so
that htey don't get overlooked and discovered unpleasantly the next
morning by bulk-builders?  Perhaps someone who does bulk builds can
comment on his level of annoyance with this sort of problem.


In general, there is a question of where to put certain types of
documentation in packages.

 pkg/DESCR   -- do i want to install this package at all?
 pkg/COMMENT

 pkg/MESSAGE -- what to do by hand after installing

Notably orphaned documentation includes:

 * ``I want to build it.  What should I know before I try to build?''  I
   know, the point of the System is to make the answer, ``nothing,'' but
   that simplpy isn't always the case.  Browsing /etc/mk.conf.example is
   definitely perfect for bulk builds, but someone building just one
   package might want to know exactly which variables influence the
   package of interest--right now, we aren't keeping track of this.

   If variable names are the only type of documentation in this category,
   I'd favour a machine-readable one-variable-per-line file, rather than
   duplicating text in mk.conf.example.  We might want to parse the file
   automatically for some reason, later on.

 * ``Suppose I want to maintain or upgrade the package.  Are there any
   caveats or tips that you, as the past maintainer, want to leave behind
   for me?''  Or, s'pose I just finished making a package and I'm angered 
   by someone's foolishness.  I want to write down why the author of XXX
   is annoying, but don't want anyone to have to read it (except,
   perhaps, a future fellow sufferer). pkg/RANT?

I like the idea of not providing a space for documentation that shouldn't
exist.  but I don't think we're quite covering all the bases yet. Maybe we
should add a few (MKCONF and RANT?) permissable files to pkg/.  Does
anyone else think there is sufficient justification for this?

-- 
Miles Nordin / v:+1 720 841-8308 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US