Bug#572064: Please provide python-uno for other python version, at least 2.6
Hi,
On Mon, Mar 01, 2010 at 05:00:18PM +0100, Jürgen Strobel wrote:
> I wanted a 2.6 variant for completely different reasons than #476213
Maybe, but this is not relevant at all.
> Waiting for packages being built in unstable solves #476213 but not my
The first "problem" of #476213 is irrelevant, the packages are installable
now with the default python; the bug originally filed there is long gone.
The request told there *later* is *exactly* what you request - to build
not only against the default python but against the other ones (here: 2.6),
too,
> I need this for a genuine python2.6 project.
Besides the factthat basing a important project on *unstable* is questionable
anyway, I'd very much buiild against 2.6, too - if it was default python.
Ask the python guys why this isn't yet and when it will be. Not me.
> > I build only for the default python and this is not going to change.
> > Especially it will get interesting because pyuno is not a pure python#
> > module but has also a OOo part (which is linked against libpython).
> >
> > Which one of both will you take? Both will conflict anyway due to
> > the pythonloader. And the build will also get hackish. ("Normal" build
> > of OOo and then pyuno again for 2.6).
> >
> > René
>
> Obviously I wanted files for both versions, including OOo parts, maybe
> installed to python2.6 lib dirs directly. I agree this is not easy and
No way. pythonloader.uno.so has to be in OOos dirs. Really.
So, yes, you would not be able to co-install them.
> time consuming as it would involve building relevant OOo components
> against both python versions. Maybe I should have asked the python guys
Yes.
> instead, but after looking at debian/rules again I doubt anyone else
> wants to understand and reproduce even parts of it.
They won't do anything there either, this is simply not only a pure
python module, but also python integration *inside* OOo. For macros,
etc. It embeds the python interpreter via libpython.
Even if you splitted the package - what would you do if a OOo linked
against libpython2.5 is supposed to execute a script uisng 2.6-features?
Or when OOo linked against libpython2.5 is supposed to execute a script
using 2.5 stuff which won't work anymore in 2.6
> I was hoping the build system would support this if you only knew the
> magic. I'll have to do with local hacks instead.
It supports building against *1* python. Anything else is hackery
and might suceed or not and will (if done correctly) result in only one
of those installable anyway.
- python-uno for the default python with the OOo stuff built against
that
- pythonX.Y-uno (X.Y != default) with the OOo stuff built aganst that
/usr/lib
/usr/lib/openoffice
/usr/lib/openoffice/basis3.2
/usr/lib/openoffice/basis3.2/program
/usr/lib/openoffice/basis3.2/program/pyuno.so
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/usr/lib/openoffice/basis3.2/program/pythonloader.uno.so
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/usr/lib/openoffice/basis3.2/program/libpyuno.so
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ etc. ]
Same files in both cases. -> conflict
Grüße/Regards,
René
--
.''`. René Engelhard -- Debian GNU/Linux Developer
: :' : http://www.debian.org | http://people.debian.org/~rene/
`. `' rene@debian.org | GnuPG-Key ID: D03E3E70
`- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70
Reply to: