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-03-2010, 11:40 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 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
 
Old 03-03-2010, 02:55 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: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
 
Old 03-03-2010, 08:39 PM
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 17:55:41 +0200
Petteri Rty <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
 
Old 03-04-2010, 06:13 AM
Petteri Rty
 
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 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
 
Old 03-04-2010, 06:39 AM
Ulrich Mueller
 
Default 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 Rty 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
 
Old 03-04-2010, 06:55 AM
Petteri Rty
 
Default 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 Rty 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
 
Old 03-04-2010, 08:43 AM
Ulrich Mueller
 
Default 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 Rty 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
 
Old 03-05-2010, 02:19 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 Thu, 4 Mar 2010 10:43:00 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Thu, 04 Mar 2010, Petteri Rty 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
 

Thread Tools




All times are GMT. The time now is 01:57 PM.

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