Paul Eggert wrote: > Here's a little bit more evidence. I just checked Debian stable, and > it has an /usr/include/lock.h, installed by an AFS development > package. See: > > http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=arla-dev&version=stable&arch=i386
This package also has a /usr/include/hash.h, which didn't collide with gnulib's hash.h in 5 years. Also, I don't see a likelihood that an application would use both gnulib and direct access to an AFS cache. > Also, distcc has a "lock.h". See <http://distcc.samba.org/>. As does > qmail <http://www.qmail.org/>. And FSP <http://fsp.sourceforge.net/>. These are all in the category "never heard of"; small projects that have reached maturity and will likely not use gnulib. And if they did, they can rename their internal lock.h file, like I did rename xmalloc.h in GNU gettext to xalloc.h for better integration with gnulib. Really, I think before we get problems with "lock.h", we would get problems with "hash.h" and "error.h". Bruno _______________________________________________ bug-gnulib mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnulib
