Bug 450692

Summary:	[pyuno] pyuno should be in default PYTHONPATH
Product:	[Fedora] Fedora	Reporter:	Alex Lancaster <alex>
Component:	openoffice.org	Assignee:	Caolan McNamara <caolanm>
Status:	CLOSED CANTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	rawhide	CC:	jnavrati
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-06-13 12:17:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	438527

Description Alex Lancaster 2008-06-10 13:49:37 UTC

import of the module doesn't work as expected:

$ python
>> import pyuno
import pyuno
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named pyuno

Of course this can be made to work by:

PYTHONPATH=/usr/lib/openoffice.org/program/ python
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) 
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyuno
>>> 

But this is a suboptimal solution because it causes practical problems with
packages that are external to openoffice.org such as bibus.  In bug #438527 the
noarch package can set the PYTHONPATH to OOo at build-time, but this will fail
on x86_64 because it will assume that OOo is located in /usr/lib/ rather than
/usr/lib64/.

As the bibus maintainer noted on the upstream bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=1989580&group_id=110943&atid=657832

"We don't have the problem under debian/ubuntu because we don't have to set
the oopath variable because in debian, pyuno is installed as a standard
python package. If it is not the case in Fedora, the best would be to ask
OOo packagers to do the same than in debian.
Just to be clear. On a stock debian:
> python
>> import uno
works without any problem. You don't have to set first:
> export LD_LIBRARY_PATH=/usr/lib/openoffice/program
> export PYTHONPATH=/usr/lib/openoffice/program
"

And I agree with him.  The Fedora package should emulate the Debian package
somehow and be installed in the standard /usr/lib/python2.5/ (or otherwise found
without recourse to setting PYTHONPATH).

This is will obviate the need for 3rd-party packages such as bibus having to do
contortions to simply import pyuno which should be in the default namespace.

Comment 1 Caolan McNamara 2008-06-10 14:08:03 UTC

debian pulls this off by a rpath to %{_libdir}/openoffice.org/program which our
guidelines (http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath)
doesn't allow

what about...

"import uno" rather than directly "import pyuno"

which imports pyuno with sufficient magic to make it work

Comment 2 Alex Lancaster 2008-06-10 14:19:14 UTC

That might be better, but it still means that 3rd-party packages (bibus in this
case) will still have special-case for Fedora, since other distros will assume
that the module should be able to be imported directly and won't see a need to
check for that module name.   Which brings us back to the original problem.

Is there any reason why OOo can't install it in the usual place and look for it
there?  I know it's very tied to OOo, but it is a Python module, after all.

Comment 3 Caolan McNamara 2008-06-10 14:33:02 UTC

I suspect that "import uno" will also works on debian et. al. If it did, that'd
be ideal.

pyuno.so does a dlopen(libpyuno.so). So if pyuno.so is moved into the python lib
dir then libpyuno.so must either be moved in there as well, and if that's moved
in there then the global linker or python path has to extended to
/usr/lib/openoffice.org because libpyuno.so links against a stack of stuff in
that dir, both options are sort of horrific.

Like I said, the debian workaround is probably the patch I see in ooo-build of...

+       @echo $(LINK) -Wl,-z,combreloc $(LINKFLAGS) $(LINKFLAGSRUNPATH_OOO)
-Wl,-rpath,/usr/lib/openoffice/program $(LINKFLAGSSHLCUI) -ldl -o $@
$(SLO)$/pyuno_dlopenwrapper.o > $(MISC)$/$(@:b).cmd

which isn't acceptable by
http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath

Comment 4 Caolan McNamara 2008-06-13 12:17:19 UTC

well "import uno" will work, and I think will work on all systems, and bring in
pyuno so that might be a suitable global upstream solution.

If someone can figure out a way to place pyuno in the right place to allow
"import pyuno" to work without violating the rpath guidelines then I'm all for it.

Maybe when the dust has settled on the 3 layer OOo it might be possible to see a
route towards placing the ure libs in standard /usr/lib path, and that might
work. But I'm not sure that it would be sufficient

Comment 5 Alex Lancaster 2008-06-13 12:34:50 UTC

If "import uno" works at the moment in actual release, then this should be
closed.    But if it doesn't yet work, then it should be kept open.  I'm not
sure why it should be closed CANTFIX, at the least, it could be closed as
UPSTREAM, since it might be fixed there.

Comment 6 Alex Lancaster 2008-06-13 12:36:48 UTC

This definitely doesn't work on F-8:

$ python
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) 
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import uno
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named uno

but it does on F-9:

$ python
Python 2.5.1 (r251:54863, Apr  8 2008, 01:19:33) 
[GCC 4.3.0 20080404 (Red Hat 4.3.0-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import uno
>>> uno

(all with most recent updates)