Building Postgres

- the link step for psql points at the libpq source directory, which
contains only the .a library, not the sharable library since that is
built on the fly during the library installation.
Comments?

I am wrong about this one (the shared library *is* built during "make
all"), but am still looking for suggestions for the right way to phase
the building for an installation. Do other platforms have statically
built apps too?

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

I am wrong about this one (the shared library *is* built during "make
all"), but am still looking for suggestions for the right way to phase
the building for an installation. Do other platforms have statically
built apps too?

The only really good, cross-platform solution that I know about is to
start using GNU "libtool" to manage the construction of the shared
libraries and the applications that depend on them. There are enough
different ways to handle (or mishandle) shared libs on different Unix
platforms that I do not think it a good use of our time to try to solve
the problem piecemeal; we'd just be reinventing libtool, probably not
very well.

I have it on my to-do list to incorporate libtool into the Postgres
build system, but I have been putting off actually doing anything,
because I don't think that the current release of libtool is quite there
on supporting multiple levels of library dependencies (pgtclsh depends
on libpgtcl.so depends on libpq.so...). This feature was originally
promised for libtool 1.3 but has been put off to 1.4.

In the meantime, I'd suggest living with the static-library build, or
else installing libpq and then repeating the build step for psql...

regards, tom lane

In the meantime, I'd suggest living with the static-library build, or
else installing libpq and then repeating the build step for psql...

For v6.5, I think I'm going to do the phased build (the "repeating"
option). But I'm pretty sure I'll do it with a patch to the top level
Makefile, and will suggest it as a feature for v6.6, so this phasing
can be repeated.

It's an interesting problem, since preparing an rpm involves building
the entire app, and then copying pieces like libraries into the binary
rpm file. For the basic pieces this looks fairly straightforward,
except for the phasing problem mentioned above, but for some packages
like perl and pythong it apparently involves modifying configuration
files in the perl or python distribution itself. Hopefully there will
be a reasonable way to do it...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

For v6.5, I think I'm going to do the phased build (the "repeating"
option).

OK, I think I've got a good start at a Postgres-6.5 rpm set. It will
have the apps using shared libraries, rather than static links. It
includes more interfaces than past rpms, including ODBC, and I've
separated out the language-specific features into separate rpms (e.g.
the tcl interfaces are in postgres-tcl-6.5-1.rpm).

I'm now trying to package the perl (and next, python) interfaces. Can
someone with perl installation experience give me some hints on what
actually needs to be installed and how it has to happen?

The Postgres source tree uses a perl-based make system which ends up
with very installation-specific and perl-version-specific target
paths, but I don't know if these paths are actually used in the final
product. Will I need to put Makefile.PL, etc., in the binary rpm
itself, and build the perl interface on the fly for every target
machine? Can I instead just plop some files into the proper place on
the target machine in a version-independent way?

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

I'm now trying to package the perl (and next, python) interfaces. Can
someone with perl installation experience give me some hints on what
actually needs to be installed and how it has to happen?

Me thinks the guy who's building the Debian packages should have some
experience with these. IIRC that'd be Oliver Elphick (?).

(just imagine, redhat and debian cooperating, hell must be freezing
over ;)

Maarten

--

Maarten Boekhold, boekhold@tibco.com
TIBCO Finance Technology Inc.
The Atrium
Strawinskylaan 3051
1077 ZX Amsterdam, The Netherlands
tel: +31 20 3012158, fax: +31 20 3012358
http://www.tibco.com

Thomas Lockhart wrote:

For v6.5, I think I'm going to do the phased build (the "repeating"
option).

OK, I think I've got a good start at a Postgres-6.5 rpm set. It will
have the apps using shared libraries, rather than static links. It
includes more interfaces than past rpms, including ODBC, and I've
separated out the language-specific features into separate rpms (e.g.
the tcl interfaces are in postgres-tcl-6.5-1.rpm).

I'm now trying to package the perl (and next, python) interfaces. Can
someone with perl installation experience give me some hints on what
actually needs to be installed and how it has to happen?

The Postgres source tree uses a perl-based make system which ends up
with very installation-specific and perl-version-specific target
paths, but I don't know if these paths are actually used in the final
product. Will I need to put Makefile.PL, etc., in the binary rpm
itself, and build the perl interface on the fly for every target
machine? Can I instead just plop some files into the proper place on
the target machine in a version-independent way?

The incantation
perl -MConfig -e 'print $Config{archlib},"\n"'

will give you the directory where things need to go.

The pm file goes directly in archlib. The sharedlib and the bootstrap
file go in <archlib>/auto/<extension-name>

<archlib>/Postgres.pm
<archlib>/auto/Postgres/Postgres.so
<archlib>/auto/Postgres/Postgres.bs

That would be a start.

---
Mark Hollomon
mhh@nortelnetworks.com

Maarten Boekhold wrote:

I'm now trying to package the perl (and next, python) interfaces. Can
someone with perl installation experience give me some hints on what
actually needs to be installed and how it has to happen?

Me thinks the guy who's building the Debian packages should have some
experience with these. IIRC that'd be Oliver Elphick (?).

The Perl package gave me the most trouble; the more so since I rarely
use Perl and only have the vaguest notion of what's going on in the pgperl
build!

Here are extracts from the Debian makefile:

HERE := $(shell pwd)
debtmp= $(HERE)/debian/tmp # pgperl package gets put in
# $(debtmp)/../libpgperl

src/config.cache:
cd src &&\
echo /usr/include/ncurses /usr/include/readline | \
./configure --prefix=$(HERE)/debian/tmp/usr/lib/postgresql \
--with-template=$(TEMPLATE) \
--with-tcl \
--enable-locale \
--with-pgport=5432

perl-config: src/config.cache
cd src/interfaces/perl5 && \
INSTALLDIRS=perl \
PREFIX=$(debtmp)/usr \
POSTGRES_HOME=$(debtmp)/usr/lib/postgresql \
INSTALLMAN1DIR=$(debtmp)/usr/man/man1 \
INSTALLMAN3DIR=$(debtmp)/usr/man/man3 \
OVERRIDE=true \
perl Makefile.PL && \
touch perl-config

perl-build: build
cp -a src/include $(debtmp)/usr/lib/postgresql/
cp src/interfaces/libpq/*.h $(debtmp)/usr/lib/postgresql/include
cd src/interfaces/perl5 && \
$(MAKE) PREFIX=$(debtmp)/usr \
POSTGRES_HOME=$(debtmp)/usr/lib/postgresql \
INSTALLDIRS=perl \
INSTALLMAN1DIR=$(debtmp)/usr/man/man1 \
INSTALLMAN3DIR=$(debtmp)/usr/man/man3 \
LDDLFLAGS="-shared -L$(debtmp)/usr/lib" \
LDFLAGS=-L../libpq \
LDLOADLIBS="-L../libpq -lpq -lc"
rm -rf $(debtmp)/usr/lib/postgresql/include

binary-arch: build-test perl-build install-python
# patch current arch into libpgperl's directory and file lists
sed 's/%ARCH%/$(ARCH)/g' <debian/libpgperl.dirs.in >debian/libpgperl.dirs
sed 's/%ARCH%/$(ARCH)/g' <debian/libpgperl.files.in >debian/libpgperl.files
dh_installdirs -a
# install files into the debian/<package> trees
...
cd src/interfaces/perl5 && \
$(MAKE) PREFIX=$(debtmp)/usr \
POSTGRES_HOME=$(debtmp)/usr/lib/postgresql \
INSTALLDIRS=perl \
INSTALLMAN1DIR=$(debtmp)/usr/man/man1 \
INSTALLMAN3DIR=$(debtmp)/usr/man/man3 \
LDDLFLAGS="-shared -L$(debtmp)/usr/lib" \
LDFLAGS=-L../libpq \
pure_install
...
rm -f debian/libpgperl/usr/lib/perl5/i386-linux/5.004/auto/Pg/.packlist
rm -rf $(debtmp)/usr/lib/perl5
rm -rf debian/libpgperl/usr/lib/perl5/i386

If you want the full works, download the Debian source package for
PostgreSQL - 6.4.2 will do (Debian's current unstable version, shortly
to be replaced by 6.5)

(just imagine, redhat and debian cooperating, hell must be freezing
over ;)

Just comfortably warm, thanks!

--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"The Spirit of the Lord is upon me, because he hath
anointed me to preach the gospel to the poor; he hath
sent me to heal the brokenhearted, to preach
deliverance to the captives, and recovering of sight
to the blind, to set at liberty them that are
bruised..." Luke 4:18

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

The Postgres source tree uses a perl-based make system which ends up
with very installation-specific and perl-version-specific target
paths, but I don't know if these paths are actually used in the final
product. Will I need to put Makefile.PL, etc., in the binary rpm
itself, and build the perl interface on the fly for every target
machine? Can I instead just plop some files into the proper place on
the target machine in a version-independent way?

I believe you would be making unsafe assumptions about both the
installed version of Perl and the location of the Perl install tree
if you do not run through the regular Perl module install procedure
("perl Makefile.PL ; make ; make install"). There is also a permissions
issue, although if rpms are normally unpacked as root that might not
matter.

I'm not very familiar with the RPM installation culture --- perhaps you
can get away with packaging a Perl module that is dependent on the
assumption that a particular existing RPM of Perl has been installed.
But I'd suggest keeping it separate from the main Postgres RPM ...

regards, tom lane

Oliver Elphick wrote:

Maarten Boekhold wrote:

I'm now trying to package the perl (and next, python) interfaces. Can
someone with perl installation experience give me some hints on what
actually needs to be installed and how it has to happen?

Me thinks the guy who's building the Debian packages should have some
experience with these. IIRC that'd be Oliver Elphick (?).

The Perl package gave me the most trouble; the more so since I rarely
use Perl and only have the vaguest notion of what's going on in the pgperl
build!

I don't know the peculiarities of every distribution, but the following
will work in any case:

tar xvzf postgres-6.5.tar.gz
cd $POSTGRES_HOME/src
./configure
make install
initdb --pgdata=/usr/local/pgsql/data --pglib=/usr/local/pgsql/lib
postmaster -S -D /usr/local/pgsql/data
createuser my_userid

make sure, the dynamic linker can find libpq.so
eg: export LD_LIBRARY_PATH=/usr/local/pgsql/lib

cd interfaces/pgsql_perl5
perl Makefile.PL
make test
su
make install

Edmund

--
Edmund Mergl
mailto:E.Mergl@bawue.de
http://www.bawue.de/~mergl

cd interfaces/pgsql_perl5
perl Makefile.PL
make test
su
make install

The rpm format would prefer to build *all* files on a source machine,
and then move them from the rpm file into the appropriate places on
target machines. The problem is that, apparently,
perl Makefile.PL
generates paths which are *very* specific to the version of perl on
the source machine, and which may not be compatible with versions of
perl on the target machines. Assuming that the code generated is a bit
more tolerant of version changes in perl, then I need to figure out
where the code would go on the target machines. One possibility is to
simply lift all of the perl5 source tree into the rpm, and actually do
the build on the target machine from scratch. afaik, this is *not* the
preferred style for rpms.

Mark Hoffman and Oliver Elphick (who also has helped with my python
questions) have given me some good clues; I'll keep asking questions
until I can get something which works...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

... Assuming that the code generated is a bit
more tolerant of version changes in perl,

I believe that's nearly as risky as hardwiring the install path.
For example, we already know that the existing perl5 interface
*source* code is broken for the latest Perl releases (5.005something),
nevermind trying to make the object code compatible. (I'm going
to try to figure out whether we can tweak the source to work under
either version ... it may take conditional compilation :-( ... if
anyone else is in a bigger hurry than me, be my guest ...)

One possibility is to
simply lift all of the perl5 source tree into the rpm, and actually do
the build on the target machine from scratch. afaik, this is *not* the
preferred style for rpms.

It may be swimming upstream in the RPM culture, but it should work
and work reliably. *Not* doing the expected configuration on the
target machine will be swimming upstream in the Perl culture, and
I'll wager that the undertow is a lot more dangerous in that case.

regards, tom lane

It may be swimming upstream in the RPM culture, but it should work
and work reliably. *Not* doing the expected configuration on the
target machine will be swimming upstream in the Perl culture, and
I'll wager that the undertow is a lot more dangerous in that case.

Yup. I'll probably end up trying to package all of the source code
into the binary rpms, with an install script. But I think my first cut
will try to force the generated files into the correct place. I've got
lots of other interfaces to handle, and want to get the rpms out as a
beta trial asap.

We'll see how long it takes someone to break the rpm :/

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Then <lockhart@alumni.caltech.edu> spoke up and said:

It may be swimming upstream in the RPM culture, but it should work
and work reliably. *Not* doing the expected configuration on the
target machine will be swimming upstream in the Perl culture, and
I'll wager that the undertow is a lot more dangerous in that case.

Yup. I'll probably end up trying to package all of the source code
into the binary rpms, with an install script. But I think my first cut
will try to force the generated files into the correct place. I've got
lots of other interfaces to handle, and want to get the rpms out as a
beta trial asap.

Wouldn't it be better to create a CPAN package and distribute it from
*there*? I realize that this method has the problem that package
updates and PostgreSQL updates could become desynchronized, but I
think this would address the issue adequately.

--
=====================================================================
| JAVA must have been developed in the wilds of West Virginia. |
| After all, why else would it support only single inheritance?? |
=====================================================================
| Finger geek@cmu.edu for my public key. |
=====================================================================

Wouldn't it be better to create a CPAN package and distribute it from
*there*? I realize that this method has the problem that package
updates and PostgreSQL updates could become desynchronized, but I
think this would address the issue adequately.

Well, the problem I'm trying to solve is rpm packaging, which is not
necessarily the same as solving the perl distribution issue.
However...

Would a CPAN package be more amenable to an rpm packaging? That is, if
we had a CPAN distribution (generated locally, of course), could I
plop that into an rpm and have a standard, easy procedure to follow
within the rpm to get the stuff extracted and installed onto a
machine?? I'm blissfully ignorant about CPAN and the packaging
conventions, but would like suggestions.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Wouldn't it be better to create a CPAN package and distribute it from
*there*?

Would a CPAN package be more amenable to an rpm packaging? That is, if
we had a CPAN distribution (generated locally, of course), could I
plop that into an rpm and have a standard, easy procedure to follow
within the rpm to get the stuff extracted and installed onto a
machine?? I'm blissfully ignorant about CPAN and the packaging
conventions, but would like suggestions.

I believe that what you find in the interfaces/perl5 subdirectory
*is* a CPAN package. Tarred and gzipped, that fileset could be
submitted to CPAN (or it could be if it was self-contained, rather than
dependent on libpq, that is). "perl Makefile.PL; make; make install"
is precisely what Perl users expect to have to do with a CPAN package.

I'm not sure if it's worth trying to come up with a self-contained
CPAN package or not --- we could probably make one, using libpq sources
and the necessary backend include files, but would it really be worth
much to anyone who didn't also have a Postgres server? Seems like you
need the full distribution anyway, in most situations.

regards, tom lane

On Tue, 29 Jun 1999, Thomas Lockhart wrote:

The rpm format would prefer to build *all* files on a source machine,
and then move them from the rpm file into the appropriate places on
target machines. The problem is that, apparently,
perl Makefile.PL
generates paths which are *very* specific to the version of perl on

That should not be the case. It depends on how the Postgres package
Makefile.PL is written, but in general it should go into a general use
perl5 directory, such as /usr/lib/perl5/site_perl, which is anything but
perl version dependant. If it generates paths that are perl version
dependent then the Makefile.PL is busted.

One possibility is to
simply lift all of the perl5 source tree into the rpm, and actually do
the build on the target machine from scratch. afaik, this is *not* the
preferred style for rpms.

No, that is definitely not th way to handle packages distributed by rpm.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.

On Mon, 28 Jun 1999, Thomas Lockhart wrote:

machine? Can I instead just plop some files into the proper place on
the target machine in a version-independent way?

On a Red Hat system you can use /usr/lib/perl5/site_perl, for example.
That is not dependent on perl version.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.

Cristian Gafton wrote:

On Tue, 29 Jun 1999, Thomas Lockhart wrote:

The rpm format would prefer to build *all* files on a source machine,
and then move them from the rpm file into the appropriate places on
target machines. The problem is that, apparently,
perl Makefile.PL
generates paths which are *very* specific to the version of perl on

That should not be the case. It depends on how the Postgres package
Makefile.PL is written, but in general it should go into a general use
perl5 directory, such as /usr/lib/perl5/site_perl, which is anything but
perl version dependant. If it generates paths that are perl version
dependent then the Makefile.PL is busted.

/usr/local/lib/perl5/site_perl/5.005/i686-linux/Pg.pm

this is the standard path for all additionally installed modules.
It depends on the perl version as well as on the system type.

One possibility is to
simply lift all of the perl5 source tree into the rpm, and actually do
the build on the target machine from scratch. afaik, this is *not* the
preferred style for rpms.

No, that is definitely not th way to handle packages distributed by rpm.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.

Edmund

--
Edmund Mergl
mailto:E.Mergl@bawue.de
http://www.bawue.de/~mergl

Cristian Gafton wrote:

On Mon, 28 Jun 1999, Thomas Lockhart wrote:

machine? Can I instead just plop some files into the proper place on
the target machine in a version-independent way?

On a Red Hat system you can use /usr/lib/perl5/site_perl, for example.
That is not dependent on perl version.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.

if you install a perl module in the standard way (make install)
on a RedHat system, you will end up with the modules installed in:

/usr/lib/perl5/site_perl/5.005/i386-linux/

A standard Makfile.PL does not contain any information about
the target directories. This is always handled by perl itself.

Edmund

--
Edmund Mergl
mailto:E.Mergl@bawue.de
http://www.bawue.de/~mergl

Cristian Gafton <gafton@redhat.com> writes:

On Tue, 29 Jun 1999, Thomas Lockhart wrote:

The problem is that, apparently,
perl Makefile.PL
generates paths which are *very* specific to the version of perl on

That should not be the case. It depends on how the Postgres package
Makefile.PL is written, but in general it should go into a general use
perl5 directory, such as /usr/lib/perl5/site_perl, which is anything but
perl version dependant. If it generates paths that are perl version
dependent then the Makefile.PL is busted.

Au contraire. That may be true for pure-Perl packages, but packages
that involve compiled code (as our perl5 interface surely does) go
into strongly version-dependent directories. On my box, for example,
the install procedure wants to put stuff into both
/opt/perl5/lib/site_perl/PA-RISC1.1/auto/Pg/ and
/opt/perl5/lib/PA-RISC1.1/5.00404/
which means it is dependent on (a) where the Perl install tree is
(/opt/perl5 is standard on SysV-derived systems, but not elsewhere),
(b) the hardware architecture (PA-RISC1.1 here), and (c) the Perl
subversion (5.004_04 here).

The dependence on hardware architecture is obviously essential, since
the compiled code could not work anywhere else. You can quibble about
whether code compiled against 5.004_04 Perl headers would work on a
wider range of Perl versions, but the fundamental bottom line is that
Perl expects addon modules to be transported in source form and
compiled against the local installation. Violating that assumption
is a recipe for trouble.

regards, tom lane

On Wed, 30 Jun 1999, Edmund Mergl wrote:

Makefile.PL is written, but in general it should go into a general use
perl5 directory, such as /usr/lib/perl5/site_perl, which is anything but
perl version dependant. If it generates paths that are perl version
dependent then the Makefile.PL is busted.

/usr/local/lib/perl5/site_perl/5.005/i686-linux/Pg.pm

You can drop it directly into /usr/local/lib/perl5/site_perl

this is the standard path for all additionally installed modules.
It depends on the perl version as well as on the system type.

Nope, this is the standard path for modules that are made to be dependent
on perl version and architecture.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.

Hi Cristian! Glad you surfaced ;)

machine? Can I instead just plop some files into the proper place on
the target machine in a version-independent way?

On a Red Hat system you can use /usr/lib/perl5/site_perl, for example.
That is not dependent on perl version.

I see that now. For some reason the postgres v6.4.2 spec file didn't
quite handle the new perl tree, but between these hints and looking at
the mod_perl package (the perl extensions for apache) I think I see
how to do things.

Thanks for the help! I'm pretty sure I'm close to having some more
capable rpms for v6.5 than we've had in the past, but it wasn't at all
trivial! It's uncovered several small problems in our make system
which prevented this from happening earlier.

I'll be posting these on the Postgres web site for folks to test;
would you like me to send you a copy directly to look at? Somehow we
should coordinate this so my postgresql-6.5-1 doesn't conflict with
one coming from a RedHat distribution...

Regards.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Cristian Gafton wrote:

On Wed, 30 Jun 1999, Edmund Mergl wrote:

Makefile.PL is written, but in general it should go into a general use
perl5 directory, such as /usr/lib/perl5/site_perl, which is anything but
perl version dependant. If it generates paths that are perl version
dependent then the Makefile.PL is busted.

/usr/local/lib/perl5/site_perl/5.005/i686-linux/Pg.pm

You can drop it directly into /usr/local/lib/perl5/site_perl

certainly you can, but you shouldn't. On our site we are running
several hundred UNIX workstations including 5 different architectures,
all of them using one NFS mounted /usr/local/lib/perl5 even with
different versions of perl. This works pretty well and relies on the
installation scheme site_perl/arch/version.
If you start dropping modules directly into site_perl you will break
this installation scheme.

this is the standard path for all additionally installed modules.
It depends on the perl version as well as on the system type.

Nope, this is the standard path for modules that are made to be dependent
on perl version and architecture.

No, if you do not prepare the Makefile.PL you will get as default the
installation scheme described above. You have to make the module explicitely
independent of architecture and version, but this is not desirable.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.

--
Edmund Mergl
mailto:E.Mergl@bawue.de
http://www.bawue.de/~mergl