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-05-2010, 05:40 PM
Duncan
 
Default 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
 
Old 03-05-2010, 06:16 PM
Mike Frysinger
 
Default 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
 
Old 03-05-2010, 07:14 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 Fri, 05 Mar 2010 13:12:36 +0200
Petteri Rty <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
 
Old 03-05-2010, 08:00 PM
Mike Frysinger
 
Default 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 Rty 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
 
Old 03-06-2010, 04:42 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/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
 

Thread Tools




All times are GMT. The time now is 08:38 PM.

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