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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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)

http://go-oo.org/discover/

please double consider go-oo

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

> 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)

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

> "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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list