Excessive dependancies for OpenOffice 2.0 port

[Mikhail Teterin]

> I fail to see how going along with the vendor's default build system and
> procedure is harder

It is harder, because:

	1) it requires re-porting -- duplicating the efforts of the other
	   ports' maintainers;
	2) it takes a lot of time to re-test. Every time openoffice@ wants
	   to do a test of a new patch/improvement/idea, they need to rebuild
	   a lot of stuff (including the entire mozilla-1.7.5). Even with
	   ccache, that's a big undertaking.

The results are also inferior, because of the outdatedness affecting (the 
proper) QA. And there may be security implications too...

> than having to massively patch around in there (and having to redo those
> patches obsoleted every time the upstream sources change significantly
> enough).

The patching required is not all that "massive". A lot of things are _already_ 
in the OOo -- there is even the "--with-system-all" flag, as well as 
"--with-system-mozilla", "--with-system-python", and 
"--without-stlport4" (modern GNU C++ has capable enough STL implementation). 
But the current maintainers are not using any of these for some reason...

> Given how outdated some of the bundled sources are, I would guess that
> OpenOffice probably would have many issues with the latest versions of its
> dependencies, requiring even more patches to OOo - or having to keep around
> obsolete versions of these dependencies in ports.

Only one such real issue came up so far -- with icu. And there is a patch for 
it already (from someone in the Linux world). I even updated our devel/icu to 
3.4, so that we can use that patch. (And sablotron, and xmlsec1, and 
dmake...)

There are also issues with Java on 64-bit platforms (or with jdk-1.5?), so I'm 
doing the --without-java here for now. We are all truly fortunate, that 
Java's licensing prevents OOo from bundling their own version with their 
source code...

(dmake's license prohibits it too, BTW, but Sun/OOo did not care).

	-mi