[OpenAFS] Re: openafs on debian with linux 2.6.18 kernel

[Marcus Watts]

#1
Somebody said FHS requires '/lib/cpp'; this is true.  Here's exactly
what it says:
	( FHS 2.3 )
f> ...
f> If a C preprocessor is installed, /lib/cpp must be a reference to it, for
f> historical reasons. [13]
f> ...
f> /lib<qual> : Alternate format essential shared libraries (optional)
f> ..
f> If one or more of these directories exist, the requirements for their contents
f> are the same as the normal /lib directory, except that /lib<qual>/cpp is not
f> required. [15]
f> ...
f> [13] The usual placement of this binary is /usr/bin/cpp.

The history not mentioned is that /lib/cpp has been where the c preprocessor
lived since at least 7th edition Unix, which even today nearly every Unix-like
vendor provides at least as an option (even FHS linux).  /usr/bin/cpp is a
comparitively recent GNUism; it is not true of AIX 4.3 xlc, nor of
solaris 8 workshop C.

Having said that, yes, I've used machines where /lib/cpp doesn't exist,
and I've even made a version of rxgen which used lwp & a hacked up
copy of cpp running in a separate thread.  I don't recommend going down
either road.  Using cpp installed anywhere else creates a much nastier
dependency problem; I have one version of rxgen that has ifdef's to select
between:
	/lib/ppc/cpp
	/usr/ccs/lib/cpp
	/usr/bin/cpp
	/lib/cpp
Only the last named path is reasonable for configure to try on its own.
The other 3 choices are each idiosyncratic, unstable, and non-portable.
I kept getting burned by discovering that the next successive
version of any particular system would move it elsewhere.

There may be confusion in the greater linux community about /lib/cpp;
but the folks that have thought about it, ie, the FHS folks, came
to one solution, and it is the same solution everybody else who goes down
this road ends up adopting.

#2
there was some confusion about what exactly debian is doing.  Conveniently
I have 3 slightly different machines, all of which run openafs.  All have
the package "cpp" installed, which according to dselect is standard:
...
    ------- Up-to-date Standard packages in section interpreters -------
 *** Std interpre cpp          4.1.1-13    4.1.1-13    The GNU C preprocessor (cpp)       
...
so I don't quite understand why you don't have this.

There are some potentialy confusing elements here:
	% dpkg -S /lib/cpp 
	dpkg: /lib/cpp not found.
	% file /lib/cpp 
	/lib/cpp: symbolic link to `/etc/alternatives/cpp'
	% /usr/sbin/update-alternatives --display /lib/cpp
	No alternatives for /lib/cpp.
	% /usr/sbin/update-alternatives --list /lib/cpp
ah, but this is mis-using update-alternatives,
	% /usr/sbin/update-alternatives --list cpp
	/usr/bin/cpp
	% /usr/sbin/update-alternatives --display cpp
	cpp - status is auto.
	 link currently points to /usr/bin/cpp
	/usr/bin/cpp - priority 10
	Current `best' version is /usr/bin/cpp.
	%

It turns out that the cpp package source has this:
	==> debian/cpp.postinst <==
	#! /bin/sh -e

	update-alternatives --quiet --install /lib/cpp cpp /usr/bin/cpp 10

	#DEBHELPER#
so that shows you how the link got created.

If you have a deb-src line in /etc/apt/sources.list, you can do this:
	apt-get source cpp
and inspect this file directly.

If you installed cpp and kept your debian binary package, you can do
something like this:
	mkdir /tmp/something
	cd /tmp/something
	ar p /var/cache/apt/archives/cpp_4%3a4.1.1-13_amd64.deb  control.tar.gz | tar xfzv -
	more postinst

Or, even if you got rid of the .deb but you still have cpp installed,
	cat /var/lib/dpkg/info/cpp.postinst

					-Marcus Watts