Re: CVS commit: pkgsrc/databases/ldb

[Roland Illig <roland.illig%gmx.de@localhost>]

On 19.05.2020 15:23, Jonathan Perkin wrote:
> * On 2020-05-19 at 08:29 BST, Roland Illig wrote:
> > On 19.05.2020 02:21, David H. Gutteridge wrote:
> > > -       mv ${CFG_CACHE} ${CFG_CACHE}.orig
> > > -       sed -E -e 's/(ENABLE_LDAP_BACKEND =) True/\1 False/g' \
> > > +       ${MV} ${CFG_CACHE} ${CFG_CACHE}.orig
> > > +       ${SED} -E -e 's/(ENABLE_LDAP_BACKEND =) True/\1 False/g' \
> >
> > To me, this change seems to be unnecessary. To double-check, I added the
> > following lines to sysutils/checkperms/Makefile:
>
> I'm not sure I like this recommendation.  It will be significantly
> slower for any commands that are wrapped rather than symlinked, which
> would include something trivially builtin like ${TRUE}, and I don't
> see any benefit.

All I wanted to say was that the assumption that "(preferred sed may not
be "sed")" was wrong.

I see now that my comment could be interpreted as a general suggestion
to use the non-variable tool names.

Since about forever, pkglint had a warning that suggested to use the
variable tools, but that suggestion only applied to the shell builtins
like TRUE, FALSE, TEST, ECHO.  This was probably to avoid strange
shells.  In the pkglint code, I came up with this explanation:

// Some of the very simple tools (echo, printf, test) differ in their
// implementations.
//
// When bmake encounters a "simple" command line, it bypasses the
// call to a shell (see devel/bmake/files/compat.c:/useShell/).
// Therefore, sometimes the shell builtin is run, and sometimes the
// native tool.
//
// In particular, this decision depends on PKG_DEBUG_LEVEL
// since that variable adds a semicolon to the command line, which is
// considered one of the characters that force the commands being
// executed by the shell. As of December 2018, the list of special
// characters is "~#=|^(){};&<>*?[]:$`\\\n".
//
// To work around this tricky situation, pkglint warns when these shell
// builtins are used by their simple names (echo, test) instead of the
// variable form (${ECHO}, ${TEST}).

We don't have any documentation that explains the practical usage of
${TOOL} vs. tool.  The pkgsrc guide only very briefly describes how to
define tools used by a package.
https://www.netbsd.org/docs/pkgsrc/pkgsrc.html#tools

I think the general consensus is to write ${TOOL} in Makefiles and to
leave the plain names for the upstream package, so that the GNU
configure scripts can just run "sed" without searching any further.

Maybe I will add this to the pkgsrc guide, I'm not entirely sure yet.

Roland