Excessive dependancies for OpenOffice 2.0 port
mi+mx at aldan.algebra.com
Mon Nov 7 10:06:48 PST 2005
> 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
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
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
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
(dmake's license prohibits it too, BTW, but Sun/OOo did not care).
More information about the freebsd-ports