Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 440180 - x11-misc/redshift: please consider using the python-r1 eclass (long story)
Summary: x11-misc/redshift: please consider using the python-r1 eclass (long story)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Sebastian Pipping
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: python-r1-tracker
  Show dependency tree
 
Reported: 2012-10-29 21:58 UTC by Michał Górny
Modified: 2013-02-17 22:42 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch migrating the ebuild to python-r1 (0007-Convert-x11-misc-redshift-to-python-r1-example.patch,2.76 KB, patch)
2012-10-29 21:58 UTC, Michał Górny
Details | Diff
Eventually applied patch (redshift-ebuild-applied.patch,2.46 KB, patch)
2013-02-17 22:41 UTC, Sebastian Pipping
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-10-29 21:58:37 UTC
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.
Comment 1 Sebastian Pipping gentoo-dev 2012-10-30 00:09:26 UTC
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?
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-10-30 05:24:40 UTC
(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.
Comment 3 Sergey Popov gentoo-dev 2012-10-30 07:22:01 UTC
desktop-effects herd does not maintain this package, but desktop-misc does. Changing CC...
Comment 4 Samuli Suominen (RETIRED) gentoo-dev 2012-10-30 07:28:57 UTC
.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?
Comment 5 Samuli Suominen (RETIRED) gentoo-dev 2012-10-30 07:31:07 UTC
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...
Comment 6 Julian Ospald 2012-10-30 11:18:21 UTC
(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?
Comment 7 Sebastian Pipping gentoo-dev 2012-10-30 11:21:55 UTC
(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!
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-10-30 17:18:19 UTC
(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.
Comment 9 Samuli Suominen (RETIRED) gentoo-dev 2012-10-30 17:34:54 UTC
(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.
Comment 10 Julian Ospald 2012-10-31 14:25:12 UTC
(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.
Comment 11 Julian Ospald 2013-01-06 19:28:59 UTC
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.
Comment 12 Mike Gilbert gentoo-dev 2013-01-06 20:08:59 UTC
(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.
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-02-16 12:04:05 UTC
Ping. Can I commit the changes already?
Comment 14 Sebastian Pipping gentoo-dev 2013-02-17 22:18:12 UTC
(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.
Comment 15 Sebastian Pipping gentoo-dev 2013-02-17 22:41:08 UTC
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.
Comment 16 Sebastian Pipping gentoo-dev 2013-02-17 22:42:35 UTC
Seems fixed to me, closing.