* [gentoo-dev] Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
@ 2010-03-02 18:27 Arfrever Frehtes Taifersar Arahesis
2010-03-03 6:52 ` Petteri Räty
0 siblings, 1 reply; 25+ messages in thread
From: Arfrever Frehtes Taifersar Arahesis @ 2010-03-02 18:27 UTC (permalink / raw
To: Gentoo Development
[-- Attachment #1.1: Type: Text/Plain, Size: 903 bytes --]
Members of Gentoo Python Project have agreed to deprecate the following functions
in EAPI <=2:
- python_version()
- python_mod_exists()
- python_tkinter_exists()
- distutils_python_version()
- distutils_python_tkinter()
These functions are already banned in EAPI >=3.
1. In this week, these functions will start printing deprecation warnings in older EAPIs.
2. On 2010-07-01, these functions will start calling die().
(If any ebuilds in gentoo-x86 still call any of these functions on 2010-07-01,
then addition of calls to die() will be delayed.)
3. On 2011-01-01, these functions will be removed.
I will also send the announcement to gentoo-dev-announce mailing list to ensure
that developers not subscribed to gentoo-dev mailing list will notice the deprecation.
The attached patch shows text of deprecation warnings.
--
Arfrever Frehtes Taifersar Arahesis
[-- Attachment #1.2: deprecation_warnings.patch --]
[-- Type: text/x-patch, Size: 2368 bytes --]
--- python.eclass
+++ python.eclass
@@ -1980,6 +1980,15 @@
die "${FUNCNAME}() cannot be used in this EAPI"
fi
+ _python_set_color_variables
+
+ if [[ "${FUNCNAME[1]}" != "distutils_python_version" ]]; then
+ ewarn
+ ewarn "${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}"
+ ewarn "${_RED}Use PYTHON() instead of python variable. Use python_get_*() instead of PYVER* variables.${_NORMAL}"
+ ewarn
+ fi
+
[[ -n "${PYVER}" ]] && return 0
local tmpstr
python="${python:-${EPREFIX}/usr/bin/python}"
@@ -2011,6 +2020,13 @@
die "${FUNCNAME}() cannot be used in this EAPI"
fi
+ _python_set_color_variables
+
+ ewarn
+ ewarn "${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}"
+ ewarn "${_RED}Use USE dependencies and/or has_version() instead of ${FUNCNAME}().${_NORMAL}"
+ ewarn
+
if [[ "$#" -ne 1 ]]; then
die "${FUNCNAME}() requires 1 argument"
fi
@@ -2027,6 +2043,15 @@
die "${FUNCNAME}() cannot be used in this EAPI"
fi
+ _python_set_color_variables
+
+ if [[ "${FUNCNAME[1]}" != "distutils_python_tkinter" ]]; then
+ ewarn
+ ewarn "${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}"
+ ewarn "${_RED}Use PYTHON_USE_WITH=\"xml\" and python_pkg_setup() instead of ${FUNCNAME}().${_NORMAL}"
+ ewarn
+ fi
+
if ! "$(PYTHON ${PYTHON_ABI})" -c "from sys import version_info
if version_info[0] == 3:
import tkinter
--- distutils.eclass
+++ distutils.eclass
@@ -382,6 +382,13 @@
die "${FUNCNAME}() cannot be used in this EAPI"
fi
+ _python_set_color_variables
+
+ ewarn
+ ewarn "${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}"
+ ewarn "${_RED}Use PYTHON() instead of python variable. Use python_get_*() instead of PYVER* variables.${_NORMAL}"
+ ewarn
+
python_version
}
@@ -394,5 +401,12 @@
die "${FUNCNAME}() cannot be used in this EAPI"
fi
+ _python_set_color_variables
+
+ ewarn
+ ewarn "${_RED}Deprecation Warning: ${FUNCNAME}() is deprecated and will be banned on 2010-07-01.${_NORMAL}"
+ ewarn "${_RED}Use PYTHON_USE_WITH=\"xml\" and python_pkg_setup() instead of ${FUNCNAME}().${_NORMAL}"
+ ewarn
+
python_tkinter_exists
}
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-02 18:27 [gentoo-dev] Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2 Arfrever Frehtes Taifersar Arahesis
@ 2010-03-03 6:52 ` Petteri Räty
2010-03-03 7:52 ` [gentoo-dev] " Ryan Hill
2010-03-03 14:02 ` [gentoo-dev] " Jeremy Olexa
0 siblings, 2 replies; 25+ messages in thread
From: Petteri Räty @ 2010-03-03 6:52 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 895 bytes --]
On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> Members of Gentoo Python Project have agreed to deprecate the following functions
> in EAPI <=2:
> - python_version()
> - python_mod_exists()
> - python_tkinter_exists()
> - distutils_python_version()
> - distutils_python_tkinter()
>
> These functions are already banned in EAPI >=3.
>
> 1. In this week, these functions will start printing deprecation warnings in older EAPIs.
> 2. On 2010-07-01, these functions will start calling die().
> (If any ebuilds in gentoo-x86 still call any of these functions on 2010-07-01,
> then addition of calls to die() will be delayed.)
> 3. On 2011-01-01, these functions will be removed.
>
Removing eclass functions like this is not allowed by current policy. If
you want to do it, you should discuss about changing policy.
Regards,
Petteri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 6:52 ` Petteri Räty
@ 2010-03-03 7:52 ` Ryan Hill
2010-03-03 8:47 ` Tomáš Chvátal
2010-03-03 14:02 ` [gentoo-dev] " Jeremy Olexa
1 sibling, 1 reply; 25+ messages in thread
From: Ryan Hill @ 2010-03-03 7:52 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]
On Wed, 03 Mar 2010 08:52:55 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> > Members of Gentoo Python Project have agreed to deprecate the following functions
> > in EAPI <=2:
> > - python_version()
> > - python_mod_exists()
> > - python_tkinter_exists()
> > - distutils_python_version()
> > - distutils_python_tkinter()
> >
> > These functions are already banned in EAPI >=3.
> >
> > 1. In this week, these functions will start printing deprecation warnings in older EAPIs.
> > 2. On 2010-07-01, these functions will start calling die().
> > (If any ebuilds in gentoo-x86 still call any of these functions on 2010-07-01,
> > then addition of calls to die() will be delayed.)
> > 3. On 2011-01-01, these functions will be removed.
> >
>
> Removing eclass functions like this is not allowed by current policy. If
> you want to do it, you should discuss about changing policy.
?!
since when?
--
fonts, by design, by neglect
gcc-porting, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 7:52 ` [gentoo-dev] " Ryan Hill
@ 2010-03-03 8:47 ` Tomáš Chvátal
2010-03-03 9:23 ` Nirbheek Chauhan
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Tomáš Chvátal @ 2010-03-03 8:47 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dne 3.3.2010 08:52, Ryan Hill napsal(a):
> On Wed, 03 Mar 2010 08:52:55 +0200
> Petteri Räty <betelgeuse@gentoo.org> wrote:
>
>> On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>>> Members of Gentoo Python Project have agreed to deprecate the following functions
>>> in EAPI <=2:
>>> - python_version()
>>> - python_mod_exists()
>>> - python_tkinter_exists()
>>> - distutils_python_version()
>>> - distutils_python_tkinter()
>>>
>>> These functions are already banned in EAPI >=3.
>>>
>>> 1. In this week, these functions will start printing deprecation warnings in older EAPIs.
>>> 2. On 2010-07-01, these functions will start calling die().
>>> (If any ebuilds in gentoo-x86 still call any of these functions on 2010-07-01,
>>> then addition of calls to die() will be delayed.)
>>> 3. On 2011-01-01, these functions will be removed.
>>>
>>
>> Removing eclass functions like this is not allowed by current policy. If
>> you want to do it, you should discuss about changing policy.
>
> ?!
>
> since when?
>
Since ever.
If you change eclass abi you need to rename it.
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuOIikACgkQHB6c3gNBRYdIoQCfXZupVWgQByemjTLbSyN6qH+H
L3IAn2yFop+l4dclIyzoCYdlGK0a/xSn
=iutE
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 8:47 ` Tomáš Chvátal
@ 2010-03-03 9:23 ` Nirbheek Chauhan
2010-03-03 11:09 ` Petteri Räty
2010-03-03 12:47 ` Ciaran McCreesh
2010-03-05 19:16 ` Mike Frysinger
2 siblings, 1 reply; 25+ messages in thread
From: Nirbheek Chauhan @ 2010-03-03 9:23 UTC (permalink / raw
To: gentoo-dev
2010/3/3 Tomáš Chvátal <scarabeus@gentoo.org>:
>>> Removing eclass functions like this is not allowed by current policy. If
>>> you want to do it, you should discuss about changing policy.
>>
>> ?!
>>
>> since when?
>>
> Since ever.
> If you change eclass abi you need to rename it.
>
I think you can *add* functions and variables to eclasses, you can
change *how* a function works internally, you can *fix* problems with
functions (which would technically result in a change in API). I don't
think it has ever been as strict as, say, the kernel ABI interface.
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 9:23 ` Nirbheek Chauhan
@ 2010-03-03 11:09 ` Petteri Räty
2010-03-03 12:40 ` Ryan Hill
0 siblings, 1 reply; 25+ messages in thread
From: Petteri Räty @ 2010-03-03 11:09 UTC (permalink / raw
To: gentoo-dev
On 3.3.2010 11.23, Nirbheek Chauhan wrote:
> 2010/3/3 Tomáš Chvátal <scarabeus@gentoo.org>:
>>>> Removing eclass functions like this is not allowed by current policy. If
>>>> you want to do it, you should discuss about changing policy.
>>>
>>> ?!
>>>
>>> since when?
>>>
>> Since ever.
>> If you change eclass abi you need to rename it.
>>
>
> I think you can *add* functions and variables to eclasses, you can
> change *how* a function works internally, you can *fix* problems with
> functions (which would technically result in a change in API). I don't
> think it has ever been as strict as, say, the kernel ABI interface.
>
Yes, eclasses go along the same lines as shared libraries, which is
probably what Tomáš meant any way.
Regards,
Petteri
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 11:09 ` Petteri Räty
@ 2010-03-03 12:40 ` Ryan Hill
2010-03-03 15:55 ` Petteri Räty
0 siblings, 1 reply; 25+ messages in thread
From: Ryan Hill @ 2010-03-03 12:40 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
On Wed, 03 Mar 2010 13:09:49 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> On 3.3.2010 11.23, Nirbheek Chauhan wrote:
> > 2010/3/3 Tomáš Chvátal <scarabeus@gentoo.org>:
> >>>> Removing eclass functions like this is not allowed by current policy. If
> >>>> you want to do it, you should discuss about changing policy.
> >>>
> >>> ?!
> >>>
> >>> since when?
> >>>
> >> Since ever.
> >> If you change eclass abi you need to rename it.
> >>
> >
> > I think you can *add* functions and variables to eclasses, you can
> > change *how* a function works internally, you can *fix* problems with
> > functions (which would technically result in a change in API). I don't
> > think it has ever been as strict as, say, the kernel ABI interface.
> >
>
> Yes, eclasses go along the same lines as shared libraries, which is
> probably what Tomáš meant any way.
Is this actually documented anywhere? Or is this another of our
"this-is-policy-because-everyone-knows-it's-policy" policies? I know there
was a technical issue with removing pkg_*_rm functions way-back-when, but if
there's no technical reason why functions can't be deprecated, and we're just
clinging to policy in the name of policy, then I can't say I see the point.
And if this is such a bad idea, then can we get it in writing?
--
fonts, by design, by neglect
gcc-porting, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 8:47 ` Tomáš Chvátal
2010-03-03 9:23 ` Nirbheek Chauhan
@ 2010-03-03 12:47 ` Ciaran McCreesh
2010-03-03 15:08 ` Duncan
2010-03-03 15:46 ` Petteri Räty
2010-03-05 19:16 ` Mike Frysinger
2 siblings, 2 replies; 25+ messages in thread
From: Ciaran McCreesh @ 2010-03-03 12:47 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 03 Mar 2010 09:47:37 +0100
Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> >> Removing eclass functions like this is not allowed by current
> >> policy. If you want to do it, you should discuss about changing
> >> policy.
> >
> > since when?
> >
> Since ever.
> If you change eclass abi you need to rename it.
No, that's not been the case 'since ever' at all. It used to be that if
you changed or removed a function, you just had to make sure you didn't
break anything. This was made more complicated by the way that eclasses
in the tree were used for removing installed packages too, which is no
longer an issue.
- --
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEARECAAYFAkuOWnAACgkQ96zL6DUtXhHcgACgj8hDz+sIgvCbqXeotvUqHyYr
v2wAoJzESPARQnPDaWhrbFNiK0zHp2G2
=RzSg
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 6:52 ` Petteri Räty
2010-03-03 7:52 ` [gentoo-dev] " Ryan Hill
@ 2010-03-03 14:02 ` Jeremy Olexa
1 sibling, 0 replies; 25+ messages in thread
From: Jeremy Olexa @ 2010-03-03 14:02 UTC (permalink / raw
To: gentoo-dev
Petteri Räty wrote:
> On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>> Members of Gentoo Python Project have agreed to deprecate the following functions
>> in EAPI <=2:
>> - python_version()
>> - python_mod_exists()
>> - python_tkinter_exists()
>> - distutils_python_version()
>> - distutils_python_tkinter()
>>
>> These functions are already banned in EAPI >=3.
>>
>> 1. In this week, these functions will start printing deprecation warnings in older EAPIs.
>> 2. On 2010-07-01, these functions will start calling die().
>> (If any ebuilds in gentoo-x86 still call any of these functions on 2010-07-01,
>> then addition of calls to die() will be delayed.)
>> 3. On 2011-01-01, these functions will be removed.
>>
>
> Removing eclass functions like this is not allowed by current policy. If
> you want to do it, you should discuss about changing policy.
That is a bogus "policy" - never heard of it myself, either.
I don't always agree with Arfrever's methods but he has thought this one
out and has a decent migration plan, imo. Sounds good to me.
-Jeremy
>
> Regards,
> Petteri
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 12:47 ` Ciaran McCreesh
@ 2010-03-03 15:08 ` Duncan
2010-03-03 15:46 ` Petteri Räty
1 sibling, 0 replies; 25+ messages in thread
From: Duncan @ 2010-03-03 15:08 UTC (permalink / raw
To: gentoo-dev
Ciaran McCreesh posted on Wed, 03 Mar 2010 12:47:41 +0000 as excerpted:
> On Wed, 03 Mar 2010 09:47:37 +0100
> Tomáš Chvátal <scarabeus@gentoo.org> wrote:
>> >> Removing eclass functions like this is not allowed by current
>> >> policy. If you want to do it, you should discuss about changing
>> >> policy.
>> >
>> > since when?
>> >
>> Since ever.
>> If you change eclass abi you need to rename it.
>
> No, that's not been the case 'since ever' at all. It used to be that if
> you changed or removed a function, you just had to make sure you didn't
> break anything. This was made more complicated by the way that eclasses
> in the tree were used for removing installed packages too, which is no
> longer an issue.
Indeed. And a long time waiting and a lot of work went into making it
possible to change eclasses without affecting uninstalls of currently
installed packages that used them.
Now that the wait is over and the work is done, are we going to forbid to
actually use it?
But I believe the policy claim was simply a misunderstanding of the
original practical requirement and the reasons behind it. With that
misunderstanding cleared up, what remains is ensuring that current in-tree
use gets fixed, and the changes are communicated so future users get it
right, as well. The proposed deprecation and migration plan does seem to
do that, altho minor quibbles on timing could be made. (It does seem most
changes like this get a year by tradition, and that would be to the "die"
phase, which would put it at March ??, 2011, with the final removal
perhaps another six months out. However, for this ~arch user, that always
seemed overly conservative, so /I'd/ not contest the shorter timing as
proposed. Someone might wish to, tho, and AFAIK the precedent would be
behind them.)
I would suggest setting /some/ sort of minimum time policy, however,
perhaps four months per phase (warning, die), thus giving folks who update
once per quarter a bit of leeway. In practice that'd push the die phase
out slightly as the deprecations are still being debated and are
presumably not in-tree yet, perhaps to mid-July if they're in by mid-month
(March), but allow removal before the end of the year.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 12:47 ` Ciaran McCreesh
2010-03-03 15:08 ` Duncan
@ 2010-03-03 15:46 ` Petteri Räty
2010-03-05 9:54 ` [gentoo-dev] " Peter Hjalmarsson
1 sibling, 1 reply; 25+ messages in thread
From: Petteri Räty @ 2010-03-03 15:46 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
On 03/03/2010 02:47 PM, Ciaran McCreesh wrote:
> On Wed, 03 Mar 2010 09:47:37 +0100
> Tomáa Chvátal <scarabeus@gentoo.org> wrote:
>>>> Removing eclass functions like this is not allowed by current
>>>> policy. If you want to do it, you should discuss about changing
>>>> policy.
>>>
>>> since when?
>>>
>> Since ever.
>> If you change eclass abi you need to rename it.
>
> No, that's not been the case 'since ever' at all. It used to be that if
> you changed or removed a function, you just had to make sure you didn't
> break anything. This was made more complicated by the way that eclasses
> in the tree were used for removing installed packages too, which is no
> longer an issue.
>
You can't fix all possible overlays so you can only start removing
functions that are used for installations if we decide we don't care
about overlays.
Regards,
Petteri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 12:40 ` Ryan Hill
@ 2010-03-03 15:55 ` Petteri Räty
2010-03-03 21:39 ` Ryan Hill
0 siblings, 1 reply; 25+ messages in thread
From: Petteri Räty @ 2010-03-03 15:55 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]
On 03/03/2010 02:40 PM, Ryan Hill wrote:
> On Wed, 03 Mar 2010 13:09:49 +0200
> Petteri Räty <betelgeuse@gentoo.org> wrote:
>
>> On 3.3.2010 11.23, Nirbheek Chauhan wrote:
>>> 2010/3/3 Tomáš Chvátal <scarabeus@gentoo.org>:
>>>>>> Removing eclass functions like this is not allowed by current policy. If
>>>>>> you want to do it, you should discuss about changing policy.
>>>>>
>>>>> ?!
>>>>>
>>>>> since when?
>>>>>
>>>> Since ever.
>>>> If you change eclass abi you need to rename it.
>>>>
>>>
>>> I think you can *add* functions and variables to eclasses, you can
>>> change *how* a function works internally, you can *fix* problems with
>>> functions (which would technically result in a change in API). I don't
>>> think it has ever been as strict as, say, the kernel ABI interface.
>>>
>>
>> Yes, eclasses go along the same lines as shared libraries, which is
>> probably what Tomáš meant any way.
>
> Is this actually documented anywhere? Or is this another of our
> "this-is-policy-because-everyone-knows-it's-policy" policies? I know there
> was a technical issue with removing pkg_*_rm functions way-back-when, but if
> there's no technical reason why functions can't be deprecated, and we're just
> clinging to policy in the name of policy, then I can't say I see the point.
>
Big eclass changes should go through gentoo-dev so someone here will
point it out at least. Devmanual should document it so I challenge
anyone to submit a patch:
http://devmanual.gentoo.org/eclass-writing/index.html
git+ssh://git.gentoo.org/var/gitroot/devmanual.git
Also policies should be changed when they don't make sense any more as I
said in my first response but I am not sure if that's the case here.
Regards,
Petteri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 15:55 ` Petteri Räty
@ 2010-03-03 21:39 ` Ryan Hill
2010-03-04 7:13 ` Petteri Räty
0 siblings, 1 reply; 25+ messages in thread
From: Ryan Hill @ 2010-03-03 21:39 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]
On Wed, 03 Mar 2010 17:55:41 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> On 03/03/2010 02:40 PM, Ryan Hill wrote:
> > Is this actually documented anywhere? Or is this another of our
> > "this-is-policy-because-everyone-knows-it's-policy" policies? I know there
> > was a technical issue with removing pkg_*_rm functions way-back-when, but if
> > there's no technical reason why functions can't be deprecated, and we're just
> > clinging to policy in the name of policy, then I can't say I see the point.
> >
>
> Big eclass changes should go through gentoo-dev so someone here will
> point it out at least. Devmanual should document it so I challenge
> anyone to submit a patch:
>
> http://devmanual.gentoo.org/eclass-writing/index.html
> git+ssh://git.gentoo.org/var/gitroot/devmanual.git
>
> Also policies should be changed when they don't make sense any more as I
> said in my first response but I am not sure if that's the case here.
The problem is I don't think this is actually a policy. One of the first
projects I did as a developer, while still under probation, was a complete
rewrite, in-place, of an eclass. Many functions were removed or renamed
(done in an overlay of course, with a migration path). It was fully reviewed,
on list, by senior devs at the time. I was told by several people that if
there were any exported pkg_post_rm or pkg_pre_rm functions, they couldn't be
touched because of portage limitations (those limitations were removed ~3
years ago now IIRC). So I wonder if this isn't just a years-long game of
Telephone where one rule passed down by word of mouth got over-generalized
and sufficiently twisted as to apply to everything.
Nor do I think it's a particularly useful policy that keeps deprecated
interfaces around forever. Careful removal with a long warning period
shouldn't actually pose a problem. I think Arfrever's plan is reasonable.
--
fonts, by design, by neglect
gcc-porting, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 21:39 ` Ryan Hill
@ 2010-03-04 7:13 ` Petteri Räty
2010-03-04 7:39 ` Ulrich Mueller
0 siblings, 1 reply; 25+ messages in thread
From: Petteri Räty @ 2010-03-04 7:13 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]
On 03/03/2010 11:39 PM, Ryan Hill wrote:
>>
>> Also policies should be changed when they don't make sense any more as I
>> said in my first response but I am not sure if that's the case here.
>
> The problem is I don't think this is actually a policy. One of the first
> projects I did as a developer, while still under probation, was a complete
> rewrite, in-place, of an eclass. Many functions were removed or renamed
> (done in an overlay of course, with a migration path). It was fully reviewed,
> on list, by senior devs at the time. I was told by several people that if
> there were any exported pkg_post_rm or pkg_pre_rm functions, they couldn't be
> touched because of portage limitations (those limitations were removed ~3
> years ago now IIRC). So I wonder if this isn't just a years-long game of
> Telephone where one rule passed down by word of mouth got over-generalized
> and sufficiently twisted as to apply to everything.
>
You can mostly get away with deprecating eclass functions in a slowly
manner.
> Nor do I think it's a particularly useful policy that keeps deprecated
> interfaces around forever. Careful removal with a long warning period
> shouldn't actually pose a problem. I think Arfrever's plan is reasonable.
>
If we decide allowing removal of functions, we should come up with a
common procedure like the eclass removal policy:
http://devmanual.gentoo.org/eclass-writing/index.html
Regards,
Petteri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-04 7:13 ` Petteri Räty
@ 2010-03-04 7:39 ` Ulrich Mueller
2010-03-04 7:55 ` Petteri Räty
0 siblings, 1 reply; 25+ messages in thread
From: Ulrich Mueller @ 2010-03-04 7:39 UTC (permalink / raw
To: gentoo-dev
>>>>> On Thu, 04 Mar 2010, Petteri Räty wrote:
> If we decide allowing removal of functions, we should come up with a
> common procedure like the eclass removal policy:
> http://devmanual.gentoo.org/eclass-writing/index.html
I think removal of functions is a special case of "Adding and Updating
Eclasses" and we already have a policy for this.
Ulrich
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-04 7:39 ` Ulrich Mueller
@ 2010-03-04 7:55 ` Petteri Räty
2010-03-04 9:43 ` Ulrich Mueller
0 siblings, 1 reply; 25+ messages in thread
From: Petteri Räty @ 2010-03-04 7:55 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
On 03/04/2010 09:39 AM, Ulrich Mueller wrote:
>>>>>> On Thu, 04 Mar 2010, Petteri Räty wrote:
>
>> If we decide allowing removal of functions, we should come up with a
>> common procedure like the eclass removal policy:
>> http://devmanual.gentoo.org/eclass-writing/index.html
>
> I think removal of functions is a special case of "Adding and Updating
> Eclasses" and we already have a policy for this.
>
> Ulrich
>
Removing functions needs a migration plan. For example how long to have
a warning there, how long before it can be removed etc. I don't see how
you can get those from the common policy?
Regards,
Petteri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-04 7:55 ` Petteri Räty
@ 2010-03-04 9:43 ` Ulrich Mueller
2010-03-05 3:19 ` Ryan Hill
0 siblings, 1 reply; 25+ messages in thread
From: Ulrich Mueller @ 2010-03-04 9:43 UTC (permalink / raw
To: gentoo-dev
>>>>> On Thu, 04 Mar 2010, Petteri Räty wrote:
>> I think removal of functions is a special case of "Adding and
>> Updating Eclasses" and we already have a policy for this.
> Removing functions needs a migration plan. For example how long to
> have a warning there, how long before it can be removed etc.
There may be no general answer to these questions. If it's an eclass
with limited scope and if the functions are no longer used in the
tree, then I don't see the need for a long transition period. OTOH,
for widespread eclasses like eutils you'd probably want it.
> I don't see how you can get those from the common policy?
"If you don't email gentoo-dev first, and end up breaking something,
expect to be in a lot of trouble."
Ulrich
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-04 9:43 ` Ulrich Mueller
@ 2010-03-05 3:19 ` Ryan Hill
0 siblings, 0 replies; 25+ messages in thread
From: Ryan Hill @ 2010-03-05 3:19 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]
On Thu, 4 Mar 2010 10:43:00 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Thu, 04 Mar 2010, Petteri Räty wrote:
>
> >> I think removal of functions is a special case of "Adding and
> >> Updating Eclasses" and we already have a policy for this.
>
> > Removing functions needs a migration plan. For example how long to
> > have a warning there, how long before it can be removed etc.
>
> There may be no general answer to these questions. If it's an eclass
> with limited scope and if the functions are no longer used in the
> tree, then I don't see the need for a long transition period. OTOH,
> for widespread eclasses like eutils you'd probably want it.
>
> > I don't see how you can get those from the common policy?
>
> "If you don't email gentoo-dev first, and end up breaking something,
> expect to be in a lot of trouble."
Now that's a policy I can get behind. :)
--
fonts, by design, by neglect
gcc-porting, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 15:46 ` Petteri Räty
@ 2010-03-05 9:54 ` Peter Hjalmarsson
2010-03-05 11:12 ` Petteri Räty
2010-03-05 18:40 ` Duncan
0 siblings, 2 replies; 25+ messages in thread
From: Peter Hjalmarsson @ 2010-03-05 9:54 UTC (permalink / raw
To: gentoo-dev
ons 2010-03-03 klockan 17:46 +0200 skrev Petteri Räty:
> On 03/03/2010 02:47 PM, Ciaran McCreesh wrote:
> > On Wed, 03 Mar 2010 09:47:37 +0100
> > Tomáa Chvátal <scarabeus@gentoo.org> wrote:
> >>>> Removing eclass functions like this is not allowed by current
> >>>> policy. If you want to do it, you should discuss about changing
> >>>> policy.
> >>>
> >>> since when?
> >>>
> >> Since ever.
> >> If you change eclass abi you need to rename it.
> >
> > No, that's not been the case 'since ever' at all. It used to be that if
> > you changed or removed a function, you just had to make sure you didn't
> > break anything. This was made more complicated by the way that eclasses
> > in the tree were used for removing installed packages too, which is no
> > longer an issue.
> >
>
> You can't fix all possible overlays so you can only start removing
> functions that are used for installations if we decide we don't care
> about overlays.
>
> Regards,
> Petteri
>
I have start to question why should we care about overlays more then the
actual portage tree?
Take for example the kernel or Xorg.
They give themselves a period of time to clean up their own code (i.e.
kernel-modules, xorg-drivers) and then they release it as stable and
tell users/distributors to upgrade.
They do not wait for nVidia/AMD/other out-of-tree drivers/modules to
catch up.
Now if we say we have someone managing an overlay, and this person do
miss this warning/die for half an year, then I would say they have nott
done their homework and they are on their own. I do not see why we
should wait unreasonable long periods of time because there may be
someone broken somewhere.
How long does Ubuntu wait for PPAs to catch up or do they expect the
managers of the PPAs to actually follow development? How about Fedora?
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-05 9:54 ` [gentoo-dev] " Peter Hjalmarsson
@ 2010-03-05 11:12 ` Petteri Räty
2010-03-05 20:14 ` [gentoo-dev] " Ryan Hill
2010-03-05 18:40 ` Duncan
1 sibling, 1 reply; 25+ messages in thread
From: Petteri Räty @ 2010-03-05 11:12 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]
On 03/05/2010 11:54 AM, Peter Hjalmarsson wrote:
>
> I have start to question why should we care about overlays more then the
> actual portage tree?
My comments do not imply caring more about overlays than the actual
portage tree.
>
> Take for example the kernel or Xorg.
> They give themselves a period of time to clean up their own code (i.e.
> kernel-modules, xorg-drivers) and then they release it as stable and
> tell users/distributors to upgrade.
> They do not wait for nVidia/AMD/other out-of-tree drivers/modules to
> catch up.
>
This doesn't match the situation in question. This more closely matches
changing for example libX11 ABI.
> Now if we say we have someone managing an overlay, and this person do
> miss this warning/die for half an year, then I would say they have nott
> done their homework and they are on their own. I do not see why we
> should wait unreasonable long periods of time because there may be
> someone broken somewhere.
>
Because there is so little benefit from removing old functions. What is
so bad about having them grouped at the bottom of the file inside a
deprecated section?
Regards,
Petteri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-05 9:54 ` [gentoo-dev] " Peter Hjalmarsson
2010-03-05 11:12 ` Petteri Räty
@ 2010-03-05 18:40 ` Duncan
1 sibling, 0 replies; 25+ messages in thread
From: Duncan @ 2010-03-05 18:40 UTC (permalink / raw
To: gentoo-dev
Peter Hjalmarsson posted on Fri, 05 Mar 2010 10:54:23 +0100 as excerpted:
> I have start to question why should we care about overlays more then the
> actual portage tree?
>
> Take for example the kernel or Xorg.
> They give themselves a period of time to clean up their own code (i.e.
> kernel-modules, xorg-drivers) and then they release it as stable and
> tell users/distributors to upgrade.
> They do not wait for nVidia/AMD/other out-of-tree drivers/modules to
> catch up.
>
> Now if we say we have someone managing an overlay, and this person do
> miss this warning/die for half an year, then I would say they have nott
> done their homework and they are on their own. I do not see why we
> should wait unreasonable long periods of time because there may be
> someone broken somewhere.
While I didn't mention overlays in my earlier reply, that's exactly why I
proposed four months each in warning and die, before removal altogether.
That gives the once-per-quarter updaters a bit of extra time to catch it
at each stage, and if they've not done so by four or even eight months
out... waiting a full year, or two, or three... isn't necessarily going to
help matters much.
Besides, if they're /that/ far behind the main tree, what sort of overlay
maintainer are they anyway? Hardly one that should be basing on Gentoo,
which has always been a "rolling" distribution.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-03 8:47 ` Tomáš Chvátal
2010-03-03 9:23 ` Nirbheek Chauhan
2010-03-03 12:47 ` Ciaran McCreesh
@ 2010-03-05 19:16 ` Mike Frysinger
2 siblings, 0 replies; 25+ messages in thread
From: Mike Frysinger @ 2010-03-05 19:16 UTC (permalink / raw
To: gentoo-dev; +Cc: Tomáš Chvátal
[-- Attachment #1: Type: Text/Plain, Size: 1642 bytes --]
On Wednesday 03 March 2010 03:47:37 Tomáš Chvátal wrote:
> Dne 3.3.2010 08:52, Ryan Hill napsal(a):
> > On Wed, 03 Mar 2010 08:52:55 +0200 Petteri Räty wrote:
> >> On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> >>> Members of Gentoo Python Project have agreed to deprecate the following
> >>> functions
> >>>
> >>> in EAPI <=2:
> >>> - python_version()
> >>> - python_mod_exists()
> >>> - python_tkinter_exists()
> >>> - distutils_python_version()
> >>> - distutils_python_tkinter()
> >>>
> >>> These functions are already banned in EAPI >=3.
> >>>
> >>> 1. In this week, these functions will start printing deprecation
> >>> warnings in older EAPIs. 2. On 2010-07-01, these functions will start
> >>> calling die().
> >>>
> >>> (If any ebuilds in gentoo-x86 still call any of these functions on
> >>> 2010-07-01,
> >>>
> >>> then addition of calls to die() will be delayed.)
> >>>
> >>> 3. On 2011-01-01, these functions will be removed.
> >>
> >> Removing eclass functions like this is not allowed by current policy. If
> >> you want to do it, you should discuss about changing policy.
> >
> > ?!
> >
> > since when?
>
> Since ever.
> If you change eclass abi you need to rename it.
erm, no. being anal about eclass removal is only because of the breakage that
occurred with installed packages. functions that get used at build time are
free to be deprecated on the fly. Arfrever has a sane set of steps that
should ease transition of everything in tree. anything out of tree (overlays)
that dont adapt deserve to die anyways.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-05 11:12 ` Petteri Räty
@ 2010-03-05 20:14 ` Ryan Hill
2010-03-05 21:00 ` Mike Frysinger
2010-03-06 5:42 ` Petteri Räty
0 siblings, 2 replies; 25+ messages in thread
From: Ryan Hill @ 2010-03-05 20:14 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]
On Fri, 05 Mar 2010 13:12:36 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> Because there is so little benefit from removing old functions. What is
> so bad about having them grouped at the bottom of the file inside a
> deprecated section?
Because then people use them. Don't ask me why. I have things I deprecated
over two years ago still being used by a dozen ebuilds bumped within the last
three months. You should be familiar with this behaviour wrt.
built_with_use. So, when I'm making changes I still have to maintain the
deprecated stuff.
If I really want to get rid of it, then I have to break it. Replace the
whole thing with a eerror like any of our deprecated eclasses. At that
point, I would rather just remove the function or eclass than curate a museum
of dead interfaces. But I suppose that's a personal quirk -- I hate having
old unused code around.
--
fonts, by design, by neglect
gcc-porting, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-05 20:14 ` [gentoo-dev] " Ryan Hill
@ 2010-03-05 21:00 ` Mike Frysinger
2010-03-06 5:42 ` Petteri Räty
1 sibling, 0 replies; 25+ messages in thread
From: Mike Frysinger @ 2010-03-05 21:00 UTC (permalink / raw
To: gentoo-dev; +Cc: Ryan Hill
[-- Attachment #1: Type: Text/Plain, Size: 1134 bytes --]
On Friday 05 March 2010 15:14:33 Ryan Hill wrote:
> On Fri, 05 Mar 2010 13:12:36 +0200 Petteri Räty wrote:
> > Because there is so little benefit from removing old functions. What is
> > so bad about having them grouped at the bottom of the file inside a
> > deprecated section?
>
> Because then people use them. Don't ask me why. I have things I
> deprecated over two years ago still being used by a dozen ebuilds bumped
> within the last three months. You should be familiar with this behaviour
> wrt.
> built_with_use. So, when I'm making changes I still have to maintain the
> deprecated stuff.
>
> If I really want to get rid of it, then I have to break it. Replace the
> whole thing with a eerror like any of our deprecated eclasses. At that
> point, I would rather just remove the function or eclass than curate a
> museum of dead interfaces. But I suppose that's a personal quirk -- I
> hate having old unused code around.
indeed ... and to take it further, ive seen devs inclined to leave ebuilds
alone even after they were told point blank the funcs were deprecated and
going away.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2
2010-03-05 20:14 ` [gentoo-dev] " Ryan Hill
2010-03-05 21:00 ` Mike Frysinger
@ 2010-03-06 5:42 ` Petteri Räty
1 sibling, 0 replies; 25+ messages in thread
From: Petteri Räty @ 2010-03-06 5:42 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
On 03/05/2010 10:14 PM, Ryan Hill wrote:
>
> Because then people use them. Don't ask me why. I have things I deprecated
> over two years ago still being used by a dozen ebuilds bumped within the last
> three months. You should be familiar with this behaviour wrt.
> built_with_use. So, when I'm making changes I still have to maintain the
> deprecated stuff.
>
built_with_use isn't using eerror and it wasn't scanned by repoman so
unless you read the whole ebuild you could miss it when bumping. If we
have devs ignoring eerrors out of the ebuild, then we should rather get
rid of them. It's much harder to spot you are using a deprecated
function when it doesn't exist at all as then the error message during
emerge doesn't stand out in any form.
Regards,
Petteri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2010-03-06 5:43 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-02 18:27 [gentoo-dev] Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2 Arfrever Frehtes Taifersar Arahesis
2010-03-03 6:52 ` Petteri Räty
2010-03-03 7:52 ` [gentoo-dev] " Ryan Hill
2010-03-03 8:47 ` Tomáš Chvátal
2010-03-03 9:23 ` Nirbheek Chauhan
2010-03-03 11:09 ` Petteri Räty
2010-03-03 12:40 ` Ryan Hill
2010-03-03 15:55 ` Petteri Räty
2010-03-03 21:39 ` Ryan Hill
2010-03-04 7:13 ` Petteri Räty
2010-03-04 7:39 ` Ulrich Mueller
2010-03-04 7:55 ` Petteri Räty
2010-03-04 9:43 ` Ulrich Mueller
2010-03-05 3:19 ` Ryan Hill
2010-03-03 12:47 ` Ciaran McCreesh
2010-03-03 15:08 ` Duncan
2010-03-03 15:46 ` Petteri Räty
2010-03-05 9:54 ` [gentoo-dev] " Peter Hjalmarsson
2010-03-05 11:12 ` Petteri Räty
2010-03-05 20:14 ` [gentoo-dev] " Ryan Hill
2010-03-05 21:00 ` Mike Frysinger
2010-03-06 5:42 ` Petteri Räty
2010-03-05 18:40 ` Duncan
2010-03-05 19:16 ` Mike Frysinger
2010-03-03 14:02 ` [gentoo-dev] " Jeremy Olexa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox