On Mon, 29 Oct 2012 11:47:36 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 29/10/12 11:42 AM, Michał Górny wrote:
> > On Mon, 29 Oct 2012 11:25:33 -0400 Ian Stakenvicius
> > <axs@gentoo.org> wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >> 
> >> On 27/10/12 07:02 AM, Micha? Górny wrote:
> >>> This serves as an example how the new functions can be used.
> >>> --- gx86/x11-misc/redshift/redshift-1.7-r1.ebuild | 33 
> >>> ++++++++++++--------------- 1 file changed, 14 insertions(+),
> >>> 19 deletions(-)
> >>> 
> >>> diff --git a/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild 
> >>> b/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild index 
> >>> f3bd210..589e571 100644 --- 
> >>> a/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild +++ 
> >>> b/gx86/x11-misc/redshift/redshift-1.7-r1.ebuild @@ -24,7 +21,8
> >>> @@ COMMON_DEPEND=">=x11-libs/libX11-1.4 x11-libs/libxcb
> >>> geoclue? ( app-misc/geoclue ) gnome? ( dev-libs/glib:2 -
> >>> >=gnome-base/gconf-2 )" +		>=gnome-base/gconf-2 ) +	gtk? (
> >>> ${PYTHON_DEPS} )" RDEPEND="${COMMON_DEPEND} gtk? (
> >>> >=dev-python/pygtk-2 dev-python/pyxdg )"
> >> 
> >> 
> >> ..should we not also ensure that the PYTHON_TARGETS for pygtk-2
> >> and pyxdg match (or at least include) the PYTHON_TARGETS being
> >> used for this package?  IE:
> >> 
> >>> RDEPEND="${COMMON_DEPEND} - 	gtk? ( >=dev-python/pygtk-2 - 
> >>> dev-python/pyxdg )" + 	gtk? (
> >>> >=dev-python/pygtk-2[$PYTHON_USEDEP] +
> >>> dev-python/pyxdg[$PYTHON_USEDEP] )"
> >> 
> >> 
> >> I don't know if this is actually needed by the package but I
> >> would assume so as it seems to be building and installing for
> >> multiple pythons..
> > 
> > Yes, of course that'd need to be done if and when pygtk and pyxdg
> > start using PYTHON_TARGETS ;).
> > 
> 
> I guess it wouldn't work to make $PYTHON_USEDEP contain
> "python_target_whatever(+)" strings so that the targets being missing
> would still allow the use deps to exist, huh...

...that sounded like a good idea...

> I'm thinking this wouldn't catch issues where the PYTHON_COMPAT of a
> dep is not as complete as the PYTHON_COMPAT of the consumer (and i
> assume we would want to error on that)

...before this part ;). So I guess it's safer to just keep it like it
is, and assume that when converting a package to p-r1, you are supposed
to check its revdeps to add $PYTHON_USEDEP whenever necessary.

-- 
Best regards,
Michał Górny