Re: Summery [was OpenOffice]
On Sun, 12 Aug 2001, Jan-Hendrik Palic wrote:
> Then, a few people diskussed, whether OpenOffice will be suitable for sid or
> not. The result is, that we put OpenOffice, when it is ready, into sid.
If something usable is finished, before sid is only in archive... I do not
think that it may go that quick.
> The next problem is the stupid buildsystem. I depends on autoconfig and
> libtool, but the buildsystem is created to build OpenOffice on
> Windows/MacOS, too.
I thinkg autoconf is not the problem there. Is is only used to create
dmake an others and with minor changes they work well. (I have the
beginning of an package for dmakge here (currently only potato), but I do
not think that working with dmake will give any good).
I'm of the opinion, that we should leave their build system where it is,
and create buildscripts for our own. (Preferably using autoconf und
helpers, as they tend to make it the right way).
This would make it possible to split opennoffice in different packages,
which can compiled of their own. ( Openoffice is highly modular and it
would be a pitty to not map modules to packages, because their buildsystem
want to build all at once. Ecspecially as they have many infrastructure
like sal or uno, that could be seen in future in other programs, too).
This would it IMHO also make is easier to package it according to
policy. Their build system is largly centered to build it in an way it
is instalable by an user. And even for system-installs there seem to be
loud voices within the upstream developers to only support it in
subsystems i.e under /usr/local or /opt but not in /usr and with
parts of config everything else in in /etc.
It may also help the porters, as upstream seems to take the CPU-tags
as subtypes of the operating system, and not as an independent thing.
(so that it checks for LinuxPPC, Linux/Alpha,Linux/ARM, FreeBSD, Irix and
NetBSD/Sparc...
> You have to use csh to set env- vars to compile it and for compiling, you
> must in the csh, too.
> And, there is no make (dist)clean, did anyone find it, me not.
This are some other disadvantages, but I think they migh have fixed this,
before we have some usable debian packages.
> The next problem is, that the source of OpenOffice includes some of libs,
> which are built as deb's for debian, for example libxmltok1.
the list in external is:
atl cpp.lcc dt glibc makefile.rc odbc psprint twain zlib
X11 audio dmake expat gpc neon pgp sane util
ado common download freetype jpeg npsdk prj std2 w4w
most of them have patches ( ecspecially within the header files ), which
may become an major pain in the ass to get this right, ecspecially as
I do not see any reason except lazyness, why OO.o should have special
version of such common libs.
> The next point is the JDK.
see my answer to the answer to this...
Hochachtungsvoll,
Bernhard R. Link
Reply to: