[PyKDE] PyKDE 3.8.0 -d option
jbublitz at nwinternet.com
Sat Nov 22 09:57:00 GMT 2003
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.
> python build.py -d /anotherarea
> Then inside pykpanelapplet/Makefile:
> -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/libpykpanelapplet.so -ln -s
> /usr/kde/3.1/lib/libpykpanelapplet.so.1 -ln -s
> /usr/kde/3.1/lib/libpykpanelapplet.so.1.0 -ln -s
> /usr/kde/3.1/lib/libpykpanelapplet.so.1.0.0 ....
> Rather than inside /anotherarea.
> Where /anotherarea could possibily be
> Other Makefiles use the -d argument fine, such as
> -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
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
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
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
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
More information about the PyQt