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/
 `. `'  r...@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to