[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OpenOffice and go-oo



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]