The following reply was made to PR pkg/34971; it has been noted by GNATS.

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/34971: www/elinks PLIST problem 
Date: Fri, 03 Nov 2006 18:21:13 +0700

     Date:        Thu,  2 Nov 2006 14:40:03 +0000 (UTC)
     From:        Lubomir Kundrak <lkundrak@redhat.com>
     Message-ID:  <20061102144003.3BF5963B9FB@narn.NetBSD.org>
 
   |  Are your sure that file really related to elinks? See locale.alias(5).
 
 And now, yes, I am sure.   I also think I know what is happening, and a (truly
 stupid) workaround for the problem - but I have no idea how to really fix it,
 that will take someone who knows how pkgsrc and PLIST files, and the
 consistency checks, really work (I will note that if the consistency check
 had not been done, there would not have been any kind of problem here, I believe).
 
 What happens is that I build packages using pkg_comp - that of itself isn't
 germane to the problem (ie: pkg_comp isn't doing anything fundamentally different)
 but it means that it is far more likely that a package will be installed into a
 virgin environment, than ever happens in a normal (non-sandbox) environment.
 
 For me, when I first built www/elinks there simply was no /usr/pkg/share/locale
 none of the packages I had built since the sandbox was last recreated had created
 that tree - that means, naturally, there was also no locale.alias file inside that
 directory.
 
 elinks installs files into /usr/pkg/share/locale - and as part of doing that (it
 seems, I didn't bother working out the mechanism) it updates the locale.alias file
 creating it if it needs to be created.   All that worked fine.
 
 However, the PLIST consistency checking saw the locale.alias file created by the
 package, where it isn't listed in the PLIST, and thus decided that something is
 broken.   I assume there is some way to tell pkgsrc that this particular file should
 be ignored for PLIST purposes.   The fix for this problem is to use that method,
 so it doesn't matter whether locale.alias existed before the package is installed
 or not.
 
 This also leads to the (stupid) workaround that allows the package to be properly
 built - simply pkg_delete it, then build it again (after it fails the first time).
 This time (assuming that the pkg_comp arena has not been destroyed in the interim)
 the locale.alias file will exist already - deleting the first attempt at elinks
 will remove all of its locale files (and I assume, rebuild the locale.alias file)
 but that doesn't seem to remove it (even though no locale files remain to own
 aliases...)   The second time elinks is built, the PLIST consistency checking doesn't
 see the file being created (as it already existed), and everything is fine.
 
 This is also why elinks would (usually) build in a non-sandbox environment, as it
 is very likely that at some time or other, some package that uses locales will have
 been installed before - however the problem I saw would occur if you attempted
 to simply "make package" in www/elinks after doing a new NetBSD installation,
 and with very few other packages installed (obviously things like digest cannot
 be avoided...)
 
 I would expect that the bulk-builds should be failing on www/elinks however, as
 they always build everything into a totally clean sandbox to look for exactly
 this kind of problem, right?