On Sat, 22 Oct 2005, Roland Illig wrote:

> The cause for this was a corrupted file(1) database, which reported "MKS Spell
> hash list (old format)" for every file and thus made the SUBST framework fail.
> Do we want to protect against this kind of error in the future? If yes, how?

Not using file(1) would be a good start.  I didn't know we did such ...
filthy heuristics.  8-)

Really, though.  SUBST_FILES has to be specified in the package anyway, so
why should we need to check if it's "text" in the opinion of file(1)?  Some
implementations of file(1) will report a file as binary if it contains any
nationalized characters at all.  This is not uncommon for scripts...!

There's a reason that we went through some pain to make libtool use a
filename pattern rather than file(1) to identify shlibs in pkgsrc.  Besides
making it work like the real linker, it avoids exactly these problems.
IMNSHO, *nothing at all* in pkgsrc infrastructure should depend on file(1).

We'd probably have to double check the uses of SUBST_FILES to make sure
there's no cases where a binary file may be "accidentally" included today,
and any cases where it is not properly detecting files as "text" which it
actually should be modifying.  Any such instances should be removed from the
affected SUBST_FILES before removing the use of file(1) from subst.mk.

More generally:  FILE_CMD should be nuked from orbit, but it is currently
used for handling the "ELF/a.out" SHLIB_TYPE in bsd.pkg.mk.  If we looked
more closely, it might be evident that some OS's using it should simply be
set to "ELF" (which I just did as I typed this -- DragonFly and UnixWare are
ELF-only), and others may have a C preprocessor define available (such as
__ELF__ on NetBSD) to get the needed value without using file(1).

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>