Re: RHEL/Centos 7 builtin vs pkgsrc zlib clash for Makefiles that include devel/zlib/buildlink3.mk

[Jason Bacon <outpaddling%yahoo.com@localhost>]

On 2020-08-19 08:10, Greg Troxel wrote:
> Jason Bacon <outpaddling%yahoo.com@localhost> writes:
>
> > On 2020-08-18 19:35, Brook Milligan wrote:
> > > Are all the yes/no options lower case as in your patch?  Shouldn't they be case insensitive?  Or are you matching prior art?
> > Good question.  Manually set mk variables can certainly take
> > case-insensitive values, but I think the command-line flags should
> > agree with the usage message: "--prefer-pkgsrc <list|yes|no>".
> >
> > If there's a consensus that the boostrap script should accept things
> > like "--prefer-pkgsrc YES" or "--prefer-pkgsrc Yes", I would be happy
> > to change it and update the usage message to match.
> >
> > I also occurs to me now that we can never have a package named "yes"
> > or "no" without breaking these flags.
> Given that the flags that are already there behave a certain way, it
> seems clear this patch should not change that, and should have the same
> yes/YES behavior as before.
>
> (If people want to talk about changing yes/YES behavior in general, I
> don't mean to say "that's prohibited".   Just "please keep separable
> changes separable".  (But I also see no reason to change.))
Looking more closely, there are other variables that are compared only 
to lower case "yes" or "no" in places, e.g.

if [ "x$preserve_path" != "xyes" ]; then
        PATH="$overpath:$PATH"
fi

case "$cwrappers" in
yes|no)
        echo "USE_CWRAPPERS=            $cwrappers" >> ${TARGET_MKCONF}

So supporting case-insensitive command-line arguments consistently would 
require some fairly extensive changes that are probably not worth the 
risk or clutter.  I don't recall any past complaints about LC-only 
bootstrap args, so I'm inclined to leave it alone.