Description: libreoffice-pyuno is needed to run python based extensions like MRI-tool etc. As much as it provides an environment for developers creating python extensions, users also need it to run ready-made python based extensions. Packages to be added: libreoffice-pyuno Comps group: @libreoffice Default: Mandatory: Visible: Multi-lib: Need to be present for arches: all
see also Bug 966796
Caolan, David - opinions?
I didn't even know there was such a group till now :-) We already have a metapackage for installing most of libreoffice. Anyway libreoffice-bsh, -pyuno and -rhino are not for development, but for using scripts written in bsh, python and javascript, respectively. They should be moved out of @libreoffice-development. I am not against adding it to @libreoffice, but it should be optional (note that it depends (in Fedora) on python3). So should -headless; it is for running libreoffice without X server. @libreoffice should contain -emailmerge and -base (as optional is enough). I would throw out -xsltfilter; the filters are generally of a poor quality (DocBook export specifically is pathetic. It does not even produce valid XML in some cases) and nobody really wants to support them. To summarize my suggestions: 1. drop -bsh, -pyuno, -rhino and -headless from @libreoffice-development 2. drop -xsltfilter from @libreoffice 3. add -emailmerge to @libreoffice 4. add -base and -pyuno to @libreoffice as optional
Done.
How does an "optional" comps entry affect "createrepo -g GROUPFILE"? Will the package get pulled in during release composes containing libreoffice? It would be odd to go running yum to install -pyuno after booting a live media with the office suite
It doesn't affect the operation of createrepo. The package itself would not be pulled into the live image, nor would it be on the DVD. (It's obviously still in the everything repo.)