From owner-freebsd-ports@FreeBSD.ORG Mon Nov 7 14:40:57 2005 Return-Path: X-Original-To: ports@FreeBSD.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EB3A16A41F; Mon, 7 Nov 2005 14:40:57 +0000 (GMT) (envelope-from quetschke@scytek.de) Received: from neptune.phys.ufl.edu (neptune.phys.ufl.edu [128.227.64.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47BC243D62; Mon, 7 Nov 2005 14:40:48 +0000 (GMT) (envelope-from quetschke@scytek.de) Received: from [127.0.0.1] (neptune.phys.ufl.edu [128.227.64.7]) by neptune.phys.ufl.edu (Postfix) with ESMTP id 4718D5FB7; Mon, 7 Nov 2005 09:40:47 -0500 (EST) Message-ID: <436F6833.9020904@scytek.de> Date: Mon, 07 Nov 2005 09:44:03 -0500 From: Volker Quetschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mikhail T." References: <200511062159.01367@Misha> In-Reply-To: <200511062159.01367@Misha> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3761A392D259A121C4E519A5" Cc: ports@FreeBSD.org, openoffice@FreeBSD.org Subject: Re: Excessive dependancies for OpenOffice 2.0 port X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 14:40:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3761A392D259A121C4E519A5 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mikhail T. wrote: > => Actually, I do realise that, and, in my opinion, it is _harder_ > => to keep it building the current way. The third-party packages -- > => installed by other ports -- have their own maintainers, who watch out > => for build problems. > > =Then I suggest that you provide the patches and feed them back to OOo > =so that the next time you don't have to do it again once a new OOo > =version comes up. Don't forget to sign the copyright agreement. > > I am doing that, but I'm NOT an OOo developer. My patches tend to be > FreeBSD-specific. FYI, I too have some experience in porting and I am > well aware of the benefits of the vendor's accepting the patches. > > "Feeding them back" to OOo is a good idea, but it should not be > holding back the progress of the FreeBSD port. And that is my point. > In "lawyers' speak", the goals of the OOo and the FreeBSD are similar, > but not identical. Maho has a "conflict of interest" -- and I feel the > FreeBSD port is under-represented. IMHO there is no conflict of interest. (I shouldn't speak for Maho here, sorry for that.) There /should/ be no conflict as we all should only want a working and easily buildable OOo. And "under-representation" is obviously not solved by working on ports and not contributing back the patches to OOo. The mysterious "someone" that represents the evil OOo can only be Maho in this case. > And, obviously, I don't care for a "copyright agreement". The patches > are/will be there for all to see, and -- by virtue of being part of a > FreeBSD port, they will, of course, be BSD-licensed. That you feel that way about the copyright assignment will only make it harder for "them" to include your patches. > => Building a special version of C compiler is, AFAIK, unprecedented. > =Feel free to work around the bugs that prohibit the use of *old* gcc > > I do feel very free, thank you. But you are not really countering my > point here... Requiring a port-specific C-compiler is unprecedented. You > stated the problem, but the lang/ooo-gcc is NOT a solution to it. Well, for a lot of linux distributions it was a solution to apply the patch to their system gcc. I assume the current FreeBSD system gcc is free of additional patches, so that would be unprecedented. ;) > =Even though you have your point that a lot of packages are included as old > =versions there is also work going on to reduce these dependencies. Did > =you ever look at the "--with-system-XXX" parameters of OOo's configure? > > Yes, OF COURSE, I did "ever look". Very nice of OOo to finally wise up > to this (1.x releases had very little flexibility in this). Too bad, > FreeBSD port does not use this, even where it can. As Maho said, there are problems (Bugs) with some of them. Maybe worth fixing? > =Also you complain about a tool (dmake) that takes roughly 10 seconds > =to build *and* that is available in the ports collection so that it > =doesn't have to be rebuild? Do you have the time to check/redo all the > =makefiles for a 300MB source package that builds just fine with dmake? > > I don't have the time (to re-write makefiles into BSD or GNU make), but > I don't object to using dmake per se. I object to using the bundled one > instead of the devel/dmake. Hmm, the OOo configure checks for an installed version of dmake, yes, platform independent, if it doesn't use the installed one and builds the included version this is a bug. But maybe just another dependency is needed. (Didn't check) > =Maybe you should check your attitude. If you stop thinking of OOo as a > =port but as an application that runs on many OSs (including FreeBSD) > =and the failure to do so as a bug we might actually get somewhere. > > I sure appreciate the OOo project and Maho's contribution to it. > But I am talking about a different thing called "FreeBSD port > editors/openoffice.org-2.0". Maho -- and, perhaps, yourself -- are OOo > developers (nothing wrong with that). I'd like a good FreeBSD port... Agreed :) > =I see that you are already familiar with the internals so that I don't > =have to point you to Jan Holesovskys (and others) work on the 64bit > =version. > > Thanks, I'm aware of Kendy's work and have exchanged e-mails with him > already as well. Jan's work for the Debian port is an example, of what > is lacking in the FreeBSD port. He even has patches, that HE KNOWS will > never be accepted "upstream". Imagine that! Yes, I don't know the specific patches here, but I can imagine that tons of #if defined(somemacro) blah #else blubb #endif constructs are likely to be rejected. It is a maintainance nightmare. And it doesn't matter if somemacro is related to 64bit or MACOSX, FREEBSD, WINDOWS, SOLARIS, you name it. Unfortunately it is a lot harder to write a nicely mainainable solution than the easy ifdef sprinkling. I also don't say that the code as is is perfect (it already has a lot of #ifdef sprinkling) but the number of supported OSs has grown and so have the expectations of the code quality. Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D --------------enig3761A392D259A121C4E519A5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDb2g3PTXJup+KeF0RArSSAKCg9TTdSdmJ5SQkt57/5Z6R0yQaIQCeOj8D d5UiLceLlC9Mbx6v3DI5+Y4= =Q9EL -----END PGP SIGNATURE----- --------------enig3761A392D259A121C4E519A5--