Subject: Re: USE_TOOLS+= gfmt
To: None <>
From: Aleksey Cheusov <>
List: tech-pkg
Date: 05/14/2006 18:53:37
> On Sun, May 14, 2006 at 02:33:23PM +0300, Aleksey Cheusov wrote:
 >> gmake, gsed, gm4, bash, ksh, tcsh, tclsh, bison, flex...
 >> all they are supported, even unzip and unzoo(!), why not gfmt?

> All of the former either follow a certain standard with the usual
> GNUification or are used extraction tools or have multiple versions
> installed. I personally don't see the need for gfmt, since only a single
> implementation is available and most pkgsrc platforms won't have it as
> host tool anyway.
Ok, unzoo is more useful than gfmt :)

> I can even think of Linux platforms without it.
Good remark. I look at the tools/ files and don't understand
why you don't implement files
like this (pseudocode, close to BSD make).

.for tool in ${all_tools}
  .if !empty(TOOLS_PLATFORM.${tool}) # do not iverride
    .if exists(/bin/${tool})
    .elif exists(/sbin/${tool})
    .elif exists(/usr/bin/${tool})
    .elif exists(/usr/sbin/${tool})

# platform specific settings
TOOLS_PLATFORM.[?=              echo  # shell builtin
TOOLS_PLATFORM.false?=          false # shell builtin
TOOLS_PLATFORM.gunzip?=         /usr/contrib/bin/gunzip # unusual path
# common setting for all platforms

1) IMO this way allows you to _minimally_ depend on system name (uname -s),
and I think that this may be very important
for such platforms as Linux which is distributed by
tens of vendors with very different set of user level tools and
even libc.
2) This was allows you to port pkgsrc to new platforms easier.

BTW, example above may be adopted to use something like
PATHS_TO_BE_SEARCHED variable if set (/usr/contrib for Interix
or /usr/xpg4/bin for Solaris, for example).

Finally, what do you think about platforms like NetBSD/FreeBSD + GNU-libc
(promoted by Debian) or OpenSolaris + APT with GNU user tools

In general, it is much better to make all necessary checks (-ldl, -lcompat,
-lcrypt, -lnsl, -lcurses ...) while bootstrapping pkgsrc, i.e. to make
all these checks run-time instead of static (inside Makefiles
for projects with no autoconf).
Otherwise, package maintainers should know all of these details.

Best regards, Aleksey Cheusov.