Subject: Re: Needed configuration variables
To: Thomas Klausner <firstname.lastname@example.org>
From: Miles Nordin <carton@Ivy.NET>
Date: 02/06/2000 19:07:12
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/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