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 _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
