See bug 18436 - epm -V pygtk-2.0.0 ..5....T /usr/lib/python2.2/site-packages/pygtk.py ..5....T /usr/lib/python2.2/site-packages/pygtk.pth ..5....T /usr/lib/python2.2/site-packages/pygtk.pyc ..5....T /usr/lib/python2.2/site-packages/pygtk.pyo Because of this problem I don't think it would be a good idea to make scigraphia depend on the old version - this would quite likely break other packages.
That's the reason why you have to reinstall pygtk-2.0 afterwards. The pygtk.py script from 0.6.11 looks like it handles calls to pygtk-0.6 (gtk-1.2) only. The pygtk.py from 2.0 seems to be able to handle both. The selection to use which library seems to be done by using the command "pygtk.require('2.0')" which probably loads pygtk-2.0. I think one way to solve this case would be to change the pygtk-2.0 ebuild to install pygtk-0.6.11 and pygtk-2.0.0 at the same time using site-packages/pygtk.p* from the 2.0-package.
Created attachment 22243 [details, diff] Preserves newer files if present The attached patch should make sure that pygtk-0.6.11 preserves the newer files if present and that these files are not uninstalled if newer pygtk is removed. Please test.
Seems to work. :) I tested it with gimp-1.3, gDesklets-0.24.1 (both pygtk-2.0) and scigraphica (pygtk-0.6).
One thing that just came to my mind regarding the patch. What happens if you remove pygtk-0.6.11 from your system? In its current state it would remove the site-packages/pygtk.p* files as well, resulting in a destroyed pygtk-2.0 installation. I made a patch for the patch which should backup the pygtk files when removing pygtk-0.6.11
Created attachment 22250 [details, diff] the patch saving the newer files upon removal of the older ones requires the first patch applied
Uh, I think this is no good idea. The patch I wrote assumed that these files would not be removed since they are claimed by two packages. Since portage does not seem to honour this (shame on me for assuming instead of testing), I'd rather not merge the 0.6.11 files instead of copying and merging the new ones. This will cause trouble if you want to keep 0.6.11 and delete 2.0.0, but that's a problem in the current state anyway. At least removing a 0.6.11 which was installed after 2.0.0 will work, then. Any better suggestions?
Created attachment 22280 [details, diff] doesn't install old files Any comments?
I would extend the patch to backup the pygtk.p* files from 0.6.11 before removing them. A new pkg_postrm() in the 2.0-ebuild would check for the existence of the backup-file (I think a .tar.bz2 in a save place on the hdd would do it) and put the old files in place keeping 0.6.11 working. The backup could be removed afterwards as well when unmerging 0.6.11.
Created attachment 22356 [details, diff] patch backing up old files This is the patch with the additions I talked about in my last comment. I'm not sure if /usr/share/pygtk is the best place for the backup, but it should be no problem to change this. Another possible addition to this path might be the -v parameter for tar, so the archives are checked.
This doesn't look good... + mv pygtk-0.6.11-backup.tar.bz2 /usr/share/pygtk/ This is a sandbox violation. Why don't you just create the file in ${D}/usr/share/pygtk/ - then you can also delete the postrm function for 0.6.x.
Yes, you're right. That's the better way. I changed the patch fixing a stupid mistake in file-detection as well.
Created attachment 22907 [details, diff] patch backing up old files v2 that's the updated patch. It fixes a mistake in file-detection as well ("if [ -x" checks for an executable not the existence).
now that i'm back, i'll have a look at this patch when i get thru my backlog of bugs
fixed in the latest 0.6.11-r1 and 2.0.0-r1, although the fix is a little different. apps that need pygtk1 explicitly should use pygtk.require(). pygtk2 is now the default if installed.
