HEADS UP: package compilation might get bumpy due to <crypt.h>'s removal on Oct 30, 2011

["Sascha Wildner" <saw@xxxxxxxxx>]

Dear user base,

the story so far:

Back in December 2010, we started installing <crypt.h> to /usr/include due  
to some misunderstanding on KDE's side regarding how to detect that KDE  
shall be linked to libcrypt (see  
https://bugs.kde.org/show_bug.cgi?id=247627 for the whole story). It  
turned out later that this was wrong (and it was also promptly fixed in  
KDE). On BSDs, crypt.h is an internal header for usage by libcrypt, but  
none that any consumer of it should need, since the relevant prototypes  
are all in <unistd.h>. I assume that crypt.h has other contents on (some)  
non-BSD systems.

As the presence of <crypt.h> in /usr/include caused other packages to  
crash (at least dircproxy was affected), I restored the old behavior  
recently (which is, don't install crypt.h) and removed it again via make  
upgrade.

Now the important catch:

It turns out that if certain packages were compiled/installed during the  
time window when crypt.h was on the system, (I know of perl and apr, but  
there might be more), they would keep this configuration (that crypt.h is  
present) in various ways. Perl, for example, will put an inclusion of  
crypt.h in its own headers (which get installed). apr will also carry this  
configuration to stuff that depends on it, for example www/apache22.

The consequence is that package compilation on systems that no longer have  
crypt.h might fail with errors complaining about not finding crypt.h if  
not all packages are recompiled. Like I said, it at least affects perl and  
apr, _so if some package depending on perl or apr fails for you with a  
"crypt.h not found" error, please recompile perl or apr_. It should  
compile again after doing that.

Sorry for the inconvenience, as I didn't know the configuration is rooted  
so deeply in some packages.

Best regards,
Sascha Wildner