GNOME Bugzilla – Bug 535524
Codegen install dir "violates" FHS
Last modified: 2011-04-20 20:15:56 UTC
By default, codegen is installed in /usr/share/pygtk/2.0/codegen/ which breaks FHS recommendations. Patch to follow puts codegen in ${pyexecdir}/gtk-2.0/codegen with the rest of pygtk. It of course also updates the pygtk pkg-config file to point to the new location. All the gnome apps and libraries that depend on pygtk I had on my system rebuilt just fine without any modifications : gnome-mag, pessulus, gedit, gnome-python*, gst-python, pygtkglext, pygtksourceview, d-feet, git, gnome-applets, gnome-menus, deskbar-applet, gnome-games, eog, gimp, rythmbox, totem, avahi, gtk-vnc, epiphany, ccsm, vte and alacarte.
Created attachment 111741 [details] [review] patch to fix codegen install location Patch that is currently applied in Gentoo to fix the issue
Personally I don't care a lot about FHS compilance, but this will probably break quite some apps.
Yes, having them in /usr/share breaks things. We end up having *.pyc and *.pyo files in /usr/share, and they can get left behind on the system or mixed up or any number of weirdnesses on python upgrades that require things to be rebuilt... all because the tools used don't find them, because they don't look into /usr/share and rightly so - it's for data files, not executable stuff like *.py, *.pyc or *.pyo.
(In reply to comment #2) > Personally I don't care a lot about FHS compilance Well, I don't really care for it either, but this specific recommendation seems to make sense and the cost to fix it seems really low. On the other hand, our QA tools really don't expect arch-specific files in /usr/share. So overall, it just seems like good idea to change it. > but this will probably break quite some apps. It'll only break those that don't use pkg-config. Which they should :) So far, we haven't found any that didn't use pkg-config. If we do, we'll of course fix and report bugs to the concerned project. And those apps will still work with unpatched versions of pygtk. Like the Numeric/Numpy migration, maybe this can be done for the next big release? Thanks
Now that codegen has moved from pygtk to pygobject, I see that the current trunk still installs it in /usr/share. Now looks like the best time to install it in the correct place. If not, what's holding this back? Thanks
Created attachment 116998 [details] [review] patch to fix codegen install location Ping again :) Any chance for this patch to land? Since codegen's name has been changed in pygobject 2.15.2 (breaking backwards compatibility), I believe it makes sense to put it in a better location. Thanks for considering this updated patch
It doesn't break backward compatibility. We now have PyGTK install a dummy script that tries to invoke new script (pygobject-codegen-2.0), so that using old name still works. I'm inclined to postpone this for 3.0 as I don't see much improvement, but there is likely a possibility to break something.
*** Bug 528066 has been marked as a duplicate of this bug. ***
We are still carrying this with 2.28 and looks to work ok
No point in fixing this now that codegen is deprecated and in maintenance mode. Closing this.