[ On Wed, December 23, 1998 at 13:00:23 (-0800), I presume I need no introduction. wrote: ]
> Subject: Re: some packages don't work well with MANZ unset...
>
> You need to explicitly *comment out* MANZ in /etc/mk.conf, if you haven't
> already done so.  I had a similar problem recently.  Or are you talking
> binary package installs?  (in which case, _why_ are you trusting it for
> ssh? :-)

Yes, that's it the problem....  (and no, I'm not installing binary
packages that I didn't build myself!  ;-)

   #                              ###
  # #    #####    ####   #    #   ###
 #   #   #    #  #    #  #    #   ###
#     #  #    #  #       ######    #
#######  #####   #  ###  #    #
#     #  #   #   #    #  #    #   ###
#     #  #    #   ####   #    #   ###

How much more misleading can one possibly get than to use variables in
so many different ways in one set of .mk files?  Are they flags?  Are
they variables?  How do you tell the difference?

Many are indeed "Possible: defined, or undefined", yet at the same time
use values such as "1" or "YES" to indicate they're turned on.  Others
explicitly use "YES" or "NO" and have default values if they're not set
in mk.conf.  One even goes so far as to say "Possible: not defined, YES"!

With what little I know about Berkeley Make's variables I don't see how
it's possible to undefine one if the default is "defined".  Clearly this
can be worked around by changing the logical sense of the flag, but I
think most people will see these things as variables, not binary flags,
esp. when some of their siblings take on enumerated values, strings,
etc.  Wouldn't it make more sense to explicitly define them as binary
variables with default values of either "YES" or "NO" (or "1" or "0"),
and cause the whole thing to barf if some illegal value is set?  Seems
to me as if this would be a little more foolproof.  This "undefined"
behaviour when a variable is defined but empty seems rather nasty.

While I'm raving about this stuff -- couldn't there be some attempt at
using better naming conventions, esp. in the pkg mk files?  AGC has
already noted one major faux pas with "LANG" for ispell....  Surely the
mk.conf name doesn't have to be the same as the one used internally in
the ispell build process.

And this may not be related, but:  A couple of packages seem to have
tripped over environment variable settings.  Gimp trips over MAILER, and
something else I installed tripped over OPT.  Both cases caused compiler
command-line syntax errors, but I can think of far worse repercussions.
Hopefully those problems are be endemic to the internal build systems of
those particular packages, but I've not tried too hard to verify this
yet.

OK, that feels better....  Now, I'd better get on to some of the less
mundane things in life....

#     #
#     #    ##    #####   #####    #   #
#     #   #  #   #    #  #    #    # #
#######  #    #  #    #  #    #     #
#     #  ######  #####   #####      #
#     #  #    #  #       #          #
#     #  #    #  #       #          #

#     #
#     #   ####   #          #    #####     ##     #   #   ####
#     #  #    #  #          #    #    #   #  #     # #   #
#######  #    #  #          #    #    #  #    #     #     ####
#     #  #    #  #          #    #    #  ######     #         #
#     #  #    #  #          #    #    #  #    #     #    #    #
#     #   ####   ######     #    #####   #    #     #     ####


-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>