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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
