[gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
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
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
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 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Fri, 05 Mar 2010 13:12:36 +0200 Petteri Räty betelge...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
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
[gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Thu, 4 Mar 2010 10:43:00 +0100 Ulrich Mueller u...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: 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 betelge...@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-
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/3/3 Tomáš Chvátal scarab...@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
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 3.3.2010 11.23, Nirbheek Chauhan wrote: 2010/3/3 Tomáš Chvátal scarab...@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
[gentoo-dev] Re: 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 13:09:49 +0200 Petteri Räty betelge...@gentoo.org wrote: On 3.3.2010 11.23, Nirbheek Chauhan wrote: 2010/3/3 Tomáš Chvátal scarab...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: 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 scarab...@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-
Re: [gentoo-dev] Re: 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 scarab...@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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: 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:40 PM, Ryan Hill wrote: On Wed, 03 Mar 2010 13:09:49 +0200 Petteri Räty betelge...@gentoo.org wrote: On 3.3.2010 11.23, Nirbheek Chauhan wrote: 2010/3/3 Tomáš Chvátal scarab...@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 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: 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 17:55:41 +0200 Petteri Räty betelge...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
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
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
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 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: 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 betelge...@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 signature.asc Description: PGP signature