Bugzilla Bug 194343

it is a FHS violation for non-portable binary files to be stored in /usr/share/

dev-python/pygtk sticks .pyc/.pyo files in there which causes problems
obviously when upgrading python versions

$ /usr/share/pygtk/2.0/codegen/ -v
dev-python/pygtk-2.12.0 (/usr/share/pygtk/2.0/codegen)
$ ls /usr/share/pygtk/2.0/codegen/*.pyc
/usr/share/pygtk/2.0/codegen/argtypes.pyc    
/usr/share/pygtk/2.0/codegen/docextract.pyc 
/usr/share/pygtk/2.0/codegen/mkskel.pyc
/usr/share/pygtk/2.0/codegen/codegen.pyc     
/usr/share/pygtk/2.0/codegen/docgen.pyc     
/usr/share/pygtk/2.0/codegen/override.pyc
/usr/share/pygtk/2.0/codegen/createdefs.pyc  
/usr/share/pygtk/2.0/codegen/h2def.pyc      
/usr/share/pygtk/2.0/codegen/reversewrapper.pyc
/usr/share/pygtk/2.0/codegen/definitions.pyc 
/usr/share/pygtk/2.0/codegen/__init__.pyc   
/usr/share/pygtk/2.0/codegen/scmexpr.pyc
/usr/share/pygtk/2.0/codegen/defsparser.pyc  
/usr/share/pygtk/2.0/codegen/mergedefs.pyc

*** Bug 217591 has been marked as a duplicate of this bug. ***

Created an attachment (id=149701) [details]
patch to install codegen into /usr/lib/python-2.x/site-packages

Patch looks good, but I don't really see the point of :

pkgpythondir = $(pyexecdir)/gtk-2.0
codegendir = $(pkgpythondir)/codegen

Why not do :

codegendir = $(pyexecdir)/gtk-2.0/codegen

...unless "pkgpythondir" is reused someplace... Am I missing something?

Patch should be sent upstream too imho :) Great stuff

(In reply to comment #3)
> Patch should be sent upstream too imho :) Great stuff

/me should have checked his inbox thoroughly before writing dumb comments :p

(In reply to comment #3)
> Patch looks good, but I don't really see the point of :
> 
> pkgpythondir = $(pyexecdir)/gtk-2.0
> codegendir = $(pkgpythondir)/codegen
> 
> Why not do :
> 
> codegendir = $(pyexecdir)/gtk-2.0/codegen

I just copied the way upstream did it for other stuff, though I do take your
point. And the set of functions exported by the python m4 macros just added to
the confusion, till I found the documentation.

(In reply to comment #5)
> I just copied the way upstream did it for other stuff, though I do take your
> point. And the set of functions exported by the python m4 macros just added to
> the confusion, till I found the documentation.

To reiterate aforementioned confusion -- I reviewed the patch again, and I
believe pkgpythondir is used by the codegen_PYTHON line below in the same
file to determine where all those .py files are sent.

Created an attachment (id=154565) [details]
patch to install codegen into /usr/lib/python-2.x/site-packages

Simpler patch, should be safer imho.

I've just committed my patch to portage on pygtk-2.12.1-r1.

Closing

After i installed the new revision i got this error while building the gimp:
/usr/bin/python: can't open file
'/lib/python2.5/site-packages/gtk-2.0/codegen/codegen.py': [Errno 2] No such
file or directory

Which is probably due to the fact that /usr/bin/pygtk-codegen-2.0 looks like
this:

#!/bin/sh

prefix=/usr
datarootdir=${prefix}/share
datadir=/usr/share
codegendir=${exec_prefix}/lib/python2.5/site-packages/gtk-2.0/codegen

PYTHONPATH=$codegendir
export PYTHONPATH

exec /usr/bin/python $codegendir/codegen.py "$@"



Note that exec_prefix isn't set anywhere...

Thanks for pointing that out.  I've fixed it.

(In reply to comment #10)
> Thanks for pointing that out.  I've fixed it.
> 

Just out of curiosity, if the old version of pygtk-2.12.1-r1 needed the
exec_prefix correction in the patch to fix this issue, why wasn't it bumped to
pygtk-2.12.1-r2?

I ask because the exec_prefix bug caused gtk-vnc not to build (see bug
#224039), and if the pygtk version number isn't bumped, doing another
emerge--sync and emerge -u world won't pull the fix in.

Rebuilding pygtk should have been enough. I've forced a revbump just to be
sure, ebuilds are identical.

Thanks

*** Bug 232279 has been marked as a duplicate of this bug. ***