Created attachment 327718 [details, diff] Patch migrating the ebuild to python-r1 Long story short, hasufell had put me to work on improving python-r1 so that x11-misc/redshift could be built with it but forgot to tell me he's not its maintainer. So if you'd like, I'm attaching a complete patch which is a result of the work I've done on it. I believe with the new eclass the ebuild is a bit simpler and cleaner. Feel free to ask if you've got any questions.
Looks interesting. Is there something like http://www.gentoo.org/proj/en/Python/developersguide.xml for -r1 in the making or a page with comparison to -r0, some kind of guide?
(In reply to comment #1) > Looks interesting. Is there something like > > http://www.gentoo.org/proj/en/Python/developersguide.xml > > for -r1 in the making or a page with comparison to -r0, some kind of guide? No, not really yet. The quick starter is: http://wiki.gentoo.org/wiki/Python-r1 but it's mostly for distutils-r1. Most of the points are still valid though.
desktop-effects herd does not maintain this package, but desktop-misc does. Changing CC...
.py[co] is now part of the package CONTENTS instead of building them in pkg_postrm and pkg_postinst? that seems stupid... or did you just forget to put the correct lines to them? why removal of >py-compile line?
somehow someone added multiple python ABI support to redshift which is completely idiotic with application. the original redshift ebuild was just building for latest 2.x series which was correct... seems this needs a bit of reverting of the ebuild currently in the tree...
(In reply to comment #5) > somehow someone added multiple python ABI support to redshift which is > completely idiotic with application. the original redshift ebuild was just > building for latest 2.x series which was correct... seems this needs a bit > of reverting of the ebuild currently in the tree... why?
(In reply to comment #5) > somehow someone added multiple python ABI support to redshift which is > completely idiotic with application. Watch your wording. For people switching from 2.6 to 2.7 or back from time to time, it's essential. > the original redshift ebuild was just > building for latest 2.x series which was correct... seems this needs a bit > of reverting of the ebuild currently in the tree... VETO!
(In reply to comment #4) > .py[co] is now part of the package CONTENTS instead of building them in > pkg_postrm and pkg_postinst? that seems stupid... or did you just forget to > put the correct lines to them? Yes, it's controlled by PM now. It has a few disadvantages but we've decided that the advantages outcome them. > why removal of >py-compile line? The line was removed in order to let the build system compile the modules.
(In reply to comment #8) > (In reply to comment #4) > > .py[co] is now part of the package CONTENTS instead of building them in > > pkg_postrm and pkg_postinst? that seems stupid... or did you just forget to > > put the correct lines to them? > > Yes, it's controlled by PM now. It has a few disadvantages but we've decided > that the advantages outcome them. > > > why removal of >py-compile line? > > The line was removed in order to let the build system compile the modules. Thanks for explanation. This is fine by me as it was done in purpose. (In reply to comment #7) > (In reply to comment #5) > > somehow someone added multiple python ABI support to redshift which is > > completely idiotic with application. > > Watch your wording. For people switching from 2.6 to 2.7 or back from time > to time, it's essential. That's why we have the tool called 'python-updater'. Multiple ABI's should be strictly put to so called 'python library packages' which are used by other packages. Otherwise it just causes completely useless (hence I said idiotic) double byte-compiling.
(In reply to comment #9) > > That's why we have the tool called 'python-updater'. Multiple ABI's should > be strictly put to so called 'python library packages' which are used by > other packages. Otherwise it just causes completely useless (hence I said > idiotic) double byte-compiling. The new eclasses force this behavior anyway (installing properly for what is selected, not partially). And python-updater is usless then. On top of it it's broken with false-positives.
what do you think Sebastian? I already use python-r1/distutils-r1 for all my packages and a few core packages like dev-python/setuptools are already migrated too.
(In reply to comment #9) > That's why we have the tool called 'python-updater'. Multiple ABI's should > be strictly put to so called 'python library packages' which are used by > other packages. Otherwise it just causes completely useless (hence I said > idiotic) double byte-compiling. Just to nitpick: technically, any package that installs files in site-packages could potentially be used as a "library" by other programs. Running python-updater is a shitty solution for people using multiple python versions. That thing is going to die with the new eclasses anyway. I enable multi-abi support whenever it is possible without significantly mangling the package. If you want to avoid building it twice (or more), then set USE_PYTHON and PYTHON_TARGETS accordingly.
Ping. Can I commit the changes already?
(In reply to comment #13) > Ping. Can I commit the changes already? No, but thanks for asking! I'm at it finally and I found a few issues left to fix: - EAPI 4 needs to be 5 or python-r5 errors out right away - "python_replicate_scripts" with trailing "s" is a misspelling of "python_replicate_script" or it was renamed in the mean time - The current use of python_foreach_impl .. pythondir="$(python_get_sitedir)" .. sets pythondir to the wrong directory for all but one version of Python. A call to a new function is needed here I'll either apply or upload a new patch for review in the next 24 hours.
Created attachment 339192 [details, diff] Eventually applied patch One more thing I found: - gtk? ( >=dev-python/pygtk-2 - dev-python/pyxdg )" + gtk? ( >=dev-python/pygtk-2[${PYTHON_USEDEP}] + dev-python/pyxdg[${PYTHON_USEDEP}] )" Attached you find what I just applied to the main tree.
Seems fixed to me, closing.