Dear all, Has there been any discussion of why Fedora ships a relatively stock (stock + 98 patches) OO.o rather than shipping go-oo? I must quickly state that I'm not interested in starting a flamewar. I've seen the extended feature set provided by go-oo such as the opengl slide transitions and I wonder what the rationale for shipping stock+patches is over shipping go-oo. Particularly when go-oo appears to contain a superset of the Fedora OO.o patches.
-- Aidan Delaney
On Mon, 2008-10-13 at 09:57 +0100, Aidan Delaney wrote:
Dear all, Has there been any discussion of why Fedora ships a relatively stock (stock + 98 patches) OO.o rather than shipping go-oo?
I judge that this route provides the stablest and best supported product for fedora users. We have a very reliable OOo in fedora. Well, we have an OOo in fedora with a very low incidence of open reported bugs, which isn't necessarily the same thing :-). My logic follows a route something like keeping the product we have closest to the product that most OOo-developers have, so that the full upstream qa and developer resources are applicable to it. With a fairly aggressive push of any fedora patches back upstream asap (where http://qa.openoffice.org/issues/show_bug.cgi?id=90439 tracks the additional patches we carry at any given time and their upstreamed issues). Currently 47 patches for 3.0, against 98 for 2.4.1. Ideally it would be 0.
the opengl slide transitions
They're still in a bit of a confused state, but I hope to see these in Fedora for F-11. I felt it was a bit much to take on for 3.0 with the simultaneous complexity of a three-layer OOo and more reliance on OOo extensions.
Particularly when go-oo appears to contain a superset of the Fedora OO.o patches.
I've no beef with ooo-build at all, and its a fine resource, and we work with them quite a bit. We carry their gstreamer stuff for example, and they carried (before it was merged into vanilla) our fontconfig glyph replacement stuff, etc. Its also possible to e.g. use ooo-build, create a fedora section in it, and in that section just reference the specific patches that would be applied in addition to vanilla. Various distributions built out of the ooo-build tree generally pick what patches in ooo-build to apply, so go-ooo.org variants can and generally do vary from eachother as to what is in them. You could think of ooo-build as a pool of available additional nifty patches and an infrastructure of picking which ones to apply.
One practical day-to-day reason for not doing that for example is that ooo-build is a set of patches, so for e.g. a security errata on OOo using ooo-build is that you can end up with patches for patches for patches, and then my brain fries and I get physically pained at the feel of limited developer time draining away into packaging administrivia.
C.
I have not tested OOo 3.0 yet
but from my previous experience I vote for go-oo
many major distros except us use go-oo (novell/suse-related, debian/ubuntu-related, Gentoo and others)
according to wikipedia one can't say it's a fork
but it's OOo with less political decisions (like relying on java for almost every thing) and go-oo fits well with fedora as it (the things I care about) rely on gst have a native support for SVG faster one can drop java and ship openoffice on a livecd (like other distros) (although I don't care about 3D transitions)
please double consider go-oo
Muayyad AlSadi wrote:
I have not tested OOo 3.0 yet
but from my previous experience I vote for go-oo
There is no opportunity for voting here. The current OpenOffice.org maintainer has explained his reasons for the path of his choice. If a alternative needs to be in Fedora, somebody must step up to maintain it.
http://fedoraproject.org/wiki/PackageMaintainers/Join
Rahul
On Mon, 2008-10-13 at 16:01 +0300, Muayyad AlSadi wrote:
go-oo fits well with fedora as it (the things I care about) rely on gst
As I said, we apply the gstreamer set of patches. FWIW Fedora was the distro that provided the additional patches (now in vanilla) to place all the *other* legacy audio stuff in OOo up on top of the audio-visual stack which sits on that Novell-provided gstreamer base.
one can drop java and ship openoffice on a livecd (like other distros) (although I don't care about 3D transitions)
Both go-ooo.org and vanilla can be configured using --without-java and both will then suffer from (in 3.0) missing help search capability, and various other random bits of java-requiring functionality. i.e. openoffice.org-base needs hsqldb to work for the local .odb format and hsqldb needs java to work. The help search requires lucene, and the xslt style-sheet filter stuff needs saxon. Its wrong to think that the go-ooo.org OOo doesn't need java to be completely functional.
C.
There is no opportunity for voting here.
I did not meant it literary
As I said, we apply the gstreamer set of patches.
I was talking about video functionality
... Both go-ooo.org and vanilla can be configured using --without-java
there is a difference between disabling java completely (--without-java) in vanilla ooo and not relying on it in ooo-core and moving it away to less frequently needed parts
in the first case you will lost most of functionality and that functionality can't be installed later but in the second case (having java but no dependence on it for ooo-core) and extra package can introduce that functionality late
for example most livecd does not need ooo-base which depends on java if you don't ship ooo-base but one should be able to add ooo-base later from the repos this is not possible if ooo is compiled with --without-java, the vanila ooo (at least 2.x) is a java monster while go-oo don't miss much functionality without java because many things in it are native
see what I have done with the vanilah https://bugzilla.redhat.com/show_bug.cgi?id=453439 (I did that before knowing that other distros uses different ooo)
On Mon, 2008-10-13 at 16:37 +0300, Muayyad AlSadi wrote:
There is no opportunity for voting here.
I did not meant it literary
As I said, we apply the gstreamer set of patches.
I was talking about video functionality
Yeah, me too. Insert->movie & sound should "just work" on Fedora, F-9 as well as F-10, and all that goes through the gstreamer stuff.It was just a mention that some extra sound stuff also goes through gstreamer (play button in the file dialog when browsing sound files, etc)
Both go-ooo.org and vanilla can be configured using --without-java
there is a difference between disabling java completely (--without-java) in vanilla ooo and not relying on it in ooo-core and moving it away to less frequently needed parts
That may be so, but its unrelated to a go-ooo vs vanilla comparison.
in the first case you will lost most of functionality and that functionality can't be installed later but in the second case (having java but no dependence on it for ooo-core) and extra package can introduce that functionality late
But rpm doesn't have any "Suggested" sort of feature, and I don't think it makes sense to just chop Requires: and leave functional menus dangling for need of user-intervention to install something else. Leaving help-search non-functional and certain menus useless unless the user has extra knowledge to install the missing requires manually to make them work is too hacky.
I've no problem with doing things the right way though. For example in F-9 we required bsh because there is a beanshell scripting engine in OOo (got only knows why, but...). Here for F-10 that I re-packaged it as a standalone openoffice.org-beanshell extension, did the right work to only see the macros->beanshell entries when beanshell is installed, etc. all of which removed the bsh require in core. That sort of thing is fine, so for e.g. the lucene if someone wants to do the work to rewrite (like I did for the an older help system to move it from some java solution to libxml/libxslt) it to use some functioning non-java solution they that'd be fine. And for the saxon one, if someone tweaked things so that the menus that refer to xslt features are only enabled/appear when saxon is available then that'd be acceptable too, especially for a fairly power-user feature like "write your own xslt transforms".
C.
But rpm doesn't have any "Suggested" sort of feature, and I don't think
we have comps.xml, and in comps we can put "default" packages which can be dropped in the livecd, but if ooo-core depends on java you can't drop it
<<EOF fine, so for e.g. the lucene if someone wants to do the work to rewrite (like I did for the an older help system to move it from some java solution to libxml/libxslt) it to use some functioning non-java solution they that'd be fine. And for the saxon one, if someone tweaked things so that the menus that refer to xslt features are only enabled/appear when saxon is available then that'd be acceptable too, especially for a fairly power-user feature like "write your own xslt transforms EOF
but in go-oo I'm told that they have replaced some java things with native replacement like some graphic things for example in sun's ooo you need java to handle SVG in go-oo you don't
so it's NOT about leaving some un-functional things
On Mon, 2008-10-13 at 19:16 +0300, Muayyad AlSadi wrote:
But rpm doesn't have any "Suggested" sort of feature, and I don't
think we have comps.xml, and in comps we can put "default" packages which can be dropped in the livecd, but if ooo-core depends on java you can't drop it
That doesn't really cut it IMO. yum install ounpenoffice.org-writer should just give you an openoffice.org writer that "just works". I'd be massively irritated if I was to install some other package and I had to guess as to what else should be installed to afterwards make it work correctly.
comps.xml is nifty for the initial recommended stuff that should be installed, but not really something that should be relied upon as a mechanism for specifying requirements for a package that are considered undesirable under some other specific circumstances. "Just working" is all that I imagine j-random-user cares about as the initial position. They may very well care that too many dependencies have been pulled in, but their base position is that everything at least works. Not working would be infuriating.
Now; Your focus seems that the java dependencies massively bloat OOo requirements, and some of that is addressed by e.g. the F-10 openoffice.org-bsh split which should avoid the wearisome "OOo requires tomecat, what a stupid program" nonsense. Some other thoughts in this area are the large gcj aot compiled .sos that come with pretty much all our java packages, but which are only used when gij is the java-of-choice and not when openjdk is the java-of-choice. I'd be interested in a solution in *that* area. i.e. right now one can install openjdk as the default java, and then install any random java package from fedora but are then forced to take the space hit of bringing the gij-specific aot .sos along with then, and also then pulling libgcj back in as a dependency of those .sos.
I would like to see OOo on the LiveCD :-), but have never gotten around to seeing what exact space is available and what sort of cunning I could employ to pretend to be small enough to fit, though I do feel that a universal LiveCD for all supported languages can only work if an awful lot of languages would play nice and not have a lot of translations or any help files :-) The last time I checked other distributions FWIW they simply limited OOo translations on their LiveCDs to the major ones that would fit. Generally < "the big 12".
but in go-oo I'm told that they have replaced some java things with native replacement like some graphic things for example in sun's ooo you need java to handle SVG in go-oo you don't
so it's NOT about leaving some un-functional things
I'm not against dropping java requirements, but I don't want to push the burden of caring about it down to the individual users. I'm totally in favour of non-java solutions for main-line functionality in OOo. svg import is sort of outside the two direct immediate usage routes that do (today) require java. Searching help, and the xsltfilter stuff are both directly available from the UI, and both need java at the moment to work right, and I don't think the right approach is to drop the Requires: on them to avoid their truly-there java dependency.
C.
"Just working" is all that I imagine j-random-user cares about as the initial position. They may very well care that too many dependencies have been pulled in, but their base position is that everything at least works. Not working would be infuriating.
said to make all that stuff to be the default to it will just work and in the same time, some one who makes the livecd could drop those extra stuff this is the point
and some of that is addressed by e.g. the F-10 openoffice.org-bsh split which should avoid the wearisome "OOo requires tomecat, what a stupid program" nonsense.
can you please make that clear for me, can I have minimal Oo.o on a fedora-based livecd without having java on it and without exceeding 700Mb limit
I would like to see OOo on the LiveCD :-),
I did it, I made a fedora based livecd with openoffice.org-{writer,impress,calc} on it http://fedoraproject.org/wiki/DerivedDistributions/LiveCDs#Ojuba_Linux
I moved away some files from ooo-core to another package so that writer,impress and calc works without java and thus can be put into a livecd and with this ojuba users can happily open .doc .rtf .odt ..etc files
but because I that on vanilla ooo many functionality could be missing because they are java-centric, while if I build it over the go-oo it will be perfect, so in Ojuba 2 if ooo3 is still java-centric and ooo-core depends on java I'll base it package on go-oo which does not
universal LiveCD for all supported languages
Ojuba is not aimed to be international, it's aimed for Arabic speakers and Fedora is aimed to be a core that is easy for people [like me] to spin it
building OOo was a nightmare, and without mock I would never be able to build it
favour of non-java solutions for main-line functionality in OOo. svg import is sort of outside the two direct immediate usage routes that do (today) require java. Searching help, and the xsltfilter stuff are both directly available from the UI, and both need java at the moment to work right, and I don't think the right
they only need java in vanilla ooo not in go-oo and this is the point behind asking you to base it on go-oo because the minimal oo.o will have more functionality and better native speed
and BTW: *filters need not be installed in the livecd
On Tue, 2008-10-14 at 01:11 +0300, Muayyad AlSadi wrote:
can you please make that clear for me, can I have minimal Oo.o on a fedora-based livecd without having java on it and without exceeding 700Mb limit
There are two explicit java-requires in stock Fedora F-10 OOo "core" rpms. One on saxon and one on lucene. So you can't put the OOo rpm on a LiveCD and not get java pulled in there as well. But there is no longer one for bsh in the "core" rpms, only on the beanshell one. Which reduces the java-requires stack somewhat if just trying to put the major OOo components on it.
I would like to see OOo on the LiveCD :-),
I did it, I made a fedora based livecd with
There's no great difficulty putting (a translation subset of) OOo on "a" LiveCD. I was referring to "the" stock fedora LiveCD.
but because I that on vanilla ooo many functionality could be missing because they are java-centric, while if I build it over the go-oo it will be perfect,
they only need java in vanilla ooo not in go-oo and this is the point behind asking you to base it on go-oo
go-ooo unfortunately is not a magic version of OOo, so it is just not the case that it can fully work without java. On such a "java-less" 3.0.0 go-ooo, or even on your own LiveCD java-less OOo of probably fedora-vanilla-based 2.4.0...
a) what happens when you run file->wizards->letter ? b) what happens when you enter a search term in the online help (note 3.0.0, not 2.4.X) ? c) what happens when you use tools->xml filter settings-> and add a new xslt transform and use "test xslts" d) and what happens when you run oobase and attempt to create a new local database.
Those examples need java to work, whether go-ooo.org or vanilla.
C.
go-ooo unfortunately is not a magic version of OOo, so it is just not the case that it can fully work without java. On such a "java-less" 3.0.0 go-ooo, or even on your own LiveCD java-less OOo of probably fedora-vanilla-based 2.4.0...
a) what happens when you run file->wizards->letter ? b) what happens when you enter a search term in the online help (note 3.0.0, not 2.4.X) ? c) what happens when you use tools->xml filter settings-> and add a new xslt transform and use "test xslts" d) and what happens when you run oobase and attempt to create a new local database.
Those examples need java to work, whether go-ooo.org or vanilla.
regarding a, c in go-oo 2.4.x they just say "please install jre package" see attachement
and b,d they are not included in the livecd they are in a separated package, anyway who needs ooo-base in a livecd, fedora livecd don't ship any replacement ooo-base
I'm not asking to make the striped openoffice the default, I'm asking to make the default behaviour in comps to be full featured, but packages dependency should allow removal of java for spinners like me, ie. rpm -qpR openoffce.org-{core,writter,impress,calc} should not mention any java dependency
On Tue, 2008-10-14 at 20:54 +0300, Muayyad AlSadi wrote:
a) what happens when you run file->wizards->letter ?
...
c) what happens when you use tools->xml filter settings-> and add a new xslt transform and use "test xslts"
...
Those examples need java to work, whether go-ooo.org or vanilla.
regarding a, c in go-oo 2.4.x they just say "please install jre package" see attachement
There's no magic go-ooo pixie dust there, that's a vanilla dialog shown when no jvm/java-infrastructure at all is found when trying to trigger java-dependant functionality. The OOo of that screen-shot hasn't found a jvm at all. If there *was* a jvm, the next stage would be to find out that the next set of requirements is missing, at which point something generally will fail silently. i.e. that dialog says "no java was found", if there *was* a java but not e.g. lucene/saxon it will say nothing and just not work. That's a miserable user experience, and people will in their thousands get into that situation and not be able to get out it.
and b,d they are not included in the livecd they are in a separated package, anyway who needs ooo-base in a livecd, fedora livecd don't ship any replacement ooo-base.
Sure, and dropping oobase from a LiveCD is reasonable, so the hsqldb requires in F-10 is now just on oobase, rather than core. My point there was that go.ooo is no different from vanilla in needing java to work correctly, and moving to go.ooo gains you very little in terms of a java-less OOo.
Not "Require:"ing the Java requirements for help and other always presented dialogs and menus that are shown as available is to fudge the reality that OOo truly does require those packages for Ooo to fulfil the contract that the UI makes with the user.
Taking "removing java from core dependencies" as the target, then the right approach is the boring slow-fix stuff to e.g. rewrite the help search to not require the java lucene stuff and to tweak the xsltfilter stuff to be a standalone expert-style feature that only appears in the menus when the xsltfilter package is installed and place the saxon requires on that subpackage, and so on for other java functionality.
Or not do any of that, and investigate further as to why exactly removing or replacing java dependencies is the target, when I last thought seriously about the area I felt the right thing to do was stop swimming against the tide and boil out some concrete standalone feature requires for gcj to be able to provide the functionality that was missing at that stage to implement the java-needs of OOo, and our fabulous java hackers simply implemented them. Your questions should be what exactly are the size figures are for requiring the java dependencies and where is that space getting used and why.
I'm not asking to make the striped openoffice the default, I'm asking to make the default behaviour in comps to be full featured, but packages dependency should allow removal of java
I think this is the wrong approach. OOo will just end up getting installed part-working an awful lot of the time and the OOo maintainer of the day will have to deal with the resulting justified bile and hatred.
I'm no lover of java, and I've previously expended effort of making OOo buildable without java for platforms that don't have a working java and on replacing java functionality with native code in some time critial build-paths, so I'm all in favour of what you want to achieve, but I don't want to compromise to make it happen.
C.
go-oo.org provides a Yum repo and a release rpm http://go-oo.mirrorbrain.org/stable/linux-i586/GoOo-release-0.0.3-0.noarch.r...
could anyone do a review/comparison for us
because there were many enhancements in the upstream oo.o 3
Caolán, On Mon, 2008-10-13 at 10:55 +0100, Caolán McNamara wrote:
I judge that this route provides the stablest and best supported product for fedora users.
Many thanks for this concise and well-considered answer. I am now convinced that though go-oo may look like it has one or two extra features on paper, the reality is that (a) these features may not be as stable as we would like and (b) these features would require too much investment of maintainer time. Where both reasons (a) and (b) should not be read as any criticism of the excellent go-oo codebase but are personal opinions.
-- Aidan Delaney
On Mon, Oct 13, 2008 at 10:55:07AM +0100, Caolán McNamara wrote:
On Mon, 2008-10-13 at 09:57 +0100, Aidan Delaney wrote:
the opengl slide transitions
They're still in a bit of a confused state, but I hope to see these in Fedora for F-11. I felt it was a bit much to take on for 3.0 with the simultaneous complexity of a three-layer OOo and more reliance on OOo extensions.
I'd love to see them earlier, if possible. They had been used as marketing material already in the 2.4.x timeline and people I have been trying to convert to using Linux & OpenOffice are referring to them and would like to see them.
I don't think they are really that useful just like compiz eye candy isn't, but it makes a difference in some parts of the target audience that currently marks this a vaporware on Fedora. E.g. from a marketing POV we should be able to offer them.
Is there an easy way for a non ooo expert to help adding them for F10 already?
Hi,
Inspired by this thread I took a look at the Finnish translations of OpenOffice in Fedora and also contacted the people who lead the Finnish L10n project of OpenOffice.
Apparently there are two sets of translations available for OpenOffice. Sun has the official translations, which are also in Fedora's OpenOffice. Then there's an unofficial collection of translations, to my knowledge someone called Pavel Janik collects those translations from the maintainers of each language and also does unofficial builds with them included. Those translations are available here:
ftp://ftp.linux.cz/pub/localization/OpenOffice.org/devel/build/Files/DEV300/
It seems the unofficial translations are in some cases much more complete than the unofficial translations. This is because the Sun Contributor Agreement process is considered to be too cumbersome and many contributors have not signed the SCA.
If someone who has not signed the SCA has contributed to the translations then these translations can't be submitted to Sun's official version anymore (unless someone goes through the trouble of identifying and taking out those parts of the translation which are made without the agreement). This is the case with the Finnish translations and so the Finnish translations included in Sun's official source code and Fedora have not been updated in three years! The situation is probably similar with other languages as well.
The unofficial translations provided by Pavel Janik are used in the Debian derivatives for example. Could Fedora also start using those, so we would get a more completely translated OpenOffice?
Ville-Pekka Vainio wrote:
It seems the unofficial translations are in some cases much more complete than the unofficial translations.
Yeah right. I meant "It seems the unofficial translations are in some cases much more complete than the _official_ translations."
Ville-Pekka Vainio wrote:
It seems the unofficial translations are in some cases much more complete than the unofficial translations. This is because the Sun Contributor Agreement process is considered to be too cumbersome and many contributors have not signed the SCA.
Is not necessarily about the SCA, but more about extra features, like the build system.
Some months ago, when it was clear that our (Romanian) translation will not be ready for 3.0, it was decided to target 3.1, but Sun was not accepting translations for 3.1, they were focused on 3.0. Also Pavel provide localized builds for *each* language every two weeks (is not easy to build OOo yourself), so it is a very useful convenience for translators who need the builds for QA their progressing work.
On Mon, 2008-10-27 at 09:11 +0200, Nicu Buculei wrote:
Is not necessarily about the SCA, but more about extra features, like the build system.
Some months ago, when it was clear that our (Romanian) translation will not be ready for 3.0, it was decided to target 3.1, but Sun was not accepting translations for 3.1, they were focused on 3.0. Also Pavel provide localized builds for *each* language every two weeks (is not easy to build OOo yourself), so it is a very useful convenience for translators who need the builds for QA their progressing work.
Yup pjanik's translation-focused work is a great resource and has helped loads of translators and translations get bootstrapped up. But just to be clear here, pjaniks builds are a additional *third* translation-focused stream, separate to ooo-build (go-ooo.org) and Sun's vanilla builds. i.e. what pops out at http://ftp.linux.cz/pub/localization/OpenOffice.org/... is a vanilla Ooo with the additional sdf files applied.
We could also add late translations (or LGPL translations that have contributors that didn't sign the Sun SCA) as extra Sources: in our .spec, as we did for a F-9 update for some Serbian translations when someone asked to have them included. Though I'm not particularly enthused about adding never-to-be-merged translations after I only got our last F-9 out-of-stream translations merged into upstream in this release.
C.
-
Aidan Delaney -
Axel Thimm -
Caolán McNamara -
Muayyad AlSadi -
Nicu Buculei -
Rahul Sundaram -
Ville-Pekka Vainio