[PyKDE] PyKDE 3.8.0 -d option

[Jim Bublitz]

On Friday November 21 2003 23:46, Russell Valentine wrote:

>    I was trying my first attempt at making a Gentoo package
> for PyKDE. I notice that not everything in PyKDE gets
> installed where you tell it to with the "-d" option. I don't
> think this was the behaviour in previous versions.

> Example:

> python build.py -d /anotherarea

> Then inside pykpanelapplet/Makefile:

> install:
>         -mv ../libs/libpykpanelapplet* /usr/kde/3.1/lib/kde3
>         -chown 0:0 /usr/kde/3.1/lib/kde3/libpykpanelapplet*
>         -rm -f /usr/kde/3.1/lib/libpykpanelapplet*
>         -ln -s
> /usr/kde/3.1/lib/kde3/libpykpanelapplet.so.1.0.0
> /usr/kde/3.1/lib/libpykpanelapplet.so -ln -s
> /usr/kde/3.1/lib/kde3/libpykpanelapplet.so.1.0.0
> /usr/kde/3.1/lib/libpykpanelapplet.so.1 -ln -s
> /usr/kde/3.1/lib/kde3/libpykpanelapplet.so.1.0.0
> /usr/kde/3.1/lib/libpykpanelapplet.so.1.0 -ln -s
> /usr/kde/3.1/lib/kde3/libpykpanelapplet.so.1.0.0
> /usr/kde/3.1/lib/libpykpanelapplet.so.1.0.0 ....

> Rather than inside /anotherarea.

> Where /anotherarea could possibily be
> /usr/lib/python2.2/site-packages/

> Other Makefiles use the -d argument fine, such as
> kpart/Makefile:

> install:
>         -cp kparts.py /anotherarea
>         -cp kparts.pyc /anotherarea
>         -mv ../libs/libkparts* /anotherarea
>         -chown 0:0 /anotherarea

> Sorry if this question is dumb, I'm new to package making.

Yep - that's changed since previous releases to accomodate panel 
applets and libpythonize (and similar stuff like KParts that's 
being released separately from PyKDE).

Some of the libs (libpykpanelapplet.so, libpythonize.so) are 
loaded by the plugin loaders of KDE apps (like kicker) so they 
need to be in specific locations so the KDE apps can find them. 
In turn, those libs need to be able to find the PyQt/PyKDE libs 
because they depend on the PyQt and PyKDE libs. 

In the latter case, the choice is between:

a. Modifying LD_LIBRARY_PATH (which distros don't seem to use 
anymore)

b. Modifying /etc/ld.so.conf to add site-packages/ or whatever 
the PyKDE module install path is

c. symlinking the PyKDE libs into directories which are 
reasonable likely to be in ld.so.conf (like /usr/lib). Python 
still wants to find the PyKDE libs in /site-packages or 
somewhere in PYTHON _PATH

a) seems like a poor choice; b) is more efficient, but seems a 
little intrusive and could really screw up a system if it fails; 
so c) is the choice I made for the PyKDE modules. The plugin 
specific stuff (libpykpanelapplet, etc) has to be in specific 
locations for KDE to find it, so a-b-c don't apply there.

"-d" should affect anything that would normally go into 
site-packages by default. Everything else has to go more or less 
where  "make install" puts it or symlinks it (or someplace 
similar).

The final symlink is for "wabbit", which I'm currently putting 
into /usr/bin (needs to be somewhere in $PATH). The actual 
script (with #!/usr/bin/env python) is  
PyKDE-3.8.0/docs/wabbit/wabbit.py.

Eventually, libpythonize should be in some other package, because 
PyQt will need it for QtDesigner plugins. Similarly, 
libpykpanelapplet will probably come out of PyKDE and go with 
the rest of the KDE plugin/extension/component stuff. 
Eventually, PyKDE should go back to what it was, but the 
symlinks for PyQt and PyKDE modules and wabbit will still be 
necessary.

About all I can afford to test is the rpm based distros - I'm not 
familiar with things like Gentoo, Debian or Debian-based 
distros, FreeBSD, etc. and don't have the machines, time, or 
knowledge to maintain copies of all of those. You can email me 
privately or on the list and I'll be happy to provide whatever 
assistance I can.

Installation is a mess because PyKDE has so many dependencies to 
begin with and now extensions are becoming dependent on PyKDE. 
Any suggestions/improvements are always welcome - I'd really 
like to cut down on the number of install problems and packaging 
problems.

Jim