FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-02-2010, 05:27 PM
Arfrever Frehtes Taifersar Arahesis
 
Default Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2

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
 
Old 03-03-2010, 05:52 AM
Petteri Ršty
 
Default Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2

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
 
Old 03-03-2010, 06:52 AM
Ryan Hill
 
Default Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2

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
 
Old 03-03-2010, 07:47 AM
Tom√°Ň° Chv√°tal
 
Default Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2

-----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/

iEYEARECAAYFAkuOIikACgkQHB6c3gNBRYdIoQCfXZupVWgQBy emjTLbSyN6qH+H
L3IAn2yFop+l4dclIyzoCYdlGK0a/xSn
=iutE
-----END PGP SIGNATURE-----
 
Old 03-03-2010, 11:47 AM
Ciaran McCreesh
 
Default Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2

-----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+sIgv CbqXeotvUqHyYr
v2wAoJzESPARQnPDaWhrbFNiK0zHp2G2
=RzSg
-----END PGP SIGNATURE-----
 
Old 03-03-2010, 01:02 PM
Jeremy Olexa
 
Default Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2

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
 
Old 03-03-2010, 02:08 PM
Duncan
 
Default Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2

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
 
Old 03-03-2010, 02:46 PM
Petteri Ršty
 
Default Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2

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
 
Old 03-05-2010, 08:54 AM
Peter Hjalmarsson
 
Default Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2

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?
 
Old 03-05-2010, 10:12 AM
Petteri Ršty
 
Default Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2

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
 

Thread Tools




All times are GMT. The time now is 04:04 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org