From owner-freebsd-openoffice@FreeBSD.ORG Mon Nov 7 18:06:48 2005 Return-Path: X-Original-To: openoffice@freebsd.org Delivered-To: freebsd-openoffice@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE76816A41F; Mon, 7 Nov 2005 18:06:48 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DBAF43D45; Mon, 7 Nov 2005 18:06:48 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com ([151.204.231.237]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IPL00EDFJM7J6J0@vms040.mailsrvcs.net>; Mon, 07 Nov 2005 12:06:08 -0600 (CST) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id jA7I62oC054210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 07 Nov 2005 13:06:06 -0500 Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id jA7I5lHW009151; Mon, 07 Nov 2005 13:05:47 -0500 Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id jA7I5jRK009150; Mon, 07 Nov 2005 13:05:45 -0500 Date: Mon, 07 Nov 2005 13:05:44 -0500 From: Mikhail Teterin In-reply-to: <200511071728.51547.lofi@freebsd.org> To: Michael Nottebrock Message-id: <200511071305.45292.mi+mx@aldan.algebra.com> Organization: Virtual Estates, Inc. MIME-version: 1.0 Content-type: text/plain; charset=koi8-u Content-transfer-encoding: 7bit Content-disposition: inline X-Virus-Scanned: ClamAV devel-20050525/1165/Sun Nov 6 00:12:58 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 References: <200511051218.09945@Misha> <200511061358.15971@Misha> <200511071728.51547.lofi@freebsd.org> X-Authentication-warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f User-Agent: KMail/1.8.2 Cc: openoffice@freebsd.org, David O'Brien , freebsd-ports@freebsd.org, Kris Kennaway Subject: Re: Excessive dependancies for OpenOffice 2.0 port X-BeenThere: freebsd-openoffice@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting OpenOffice to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 18:06:48 -0000 > 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