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, 11:19 PM
Zac Medico
 
Default Python 3.1: Stabilization and news item

On 03/05/2010 11:26 AM, Duncan wrote:
> Zac Medico posted on Fri, 05 Mar 2010 03:24:29 -0800 as excerpted:
>
>> On 03/05/2010 03:09 AM, Maciej Mrozowski wrote:
>>> Now on more serious note, ideally python could be treated just like any
>>> other non-leaf package (in dependency tree), just like library. In such
>>> case it's completely reasonable to stabilize the newest version of such
>>> 'library', especially when it's slotted and doesn't conflict in any way
>>> with the rest. However, because of being used by package manager,
>>> python is leaf application really and it's going to be immediately
>>> pulled for everyone.
>>
>> It won't be pulled in by sys-apps/portage dependencies which look like
>> this:
>>
>> || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6
>>> =dev-lang/python-3 )
>>
>> If you already have python:2.6 installed then it will not pull in a new
>> slot.
>
> Won't emerge -aNuD pull it in anyway, even in a new slot, since portage
> says it can use it? I know I use that, so I'm always updated all the way
> thru the system, not just at the leaves.

No, it won't. To prove it, I've just tested with a stable stage3
containing portage-2.1.7.x. Here are the steps:

1) extract stable stage3 and chroot into it
2) mkdir /etc/portage && echo "dev-lang/python ~*" >>
/etc/portage/package.keywords
3) Run `emerge -pu --deep=1 portage`:
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild UD] sys-apps/sandbox-1.6-r2 [2.2]
[ebuild UD] app-shells/bash-4.0_p35 [4.0_p37]
[ebuild U ] dev-lang/python-2.6.4-r1 [2.6.4]

If you try `emerge -puD world` then you will see
dev-lang/python-3.1.1-r1 pulled in by the unspecific dev-lang/python
atoms in the cracklib and libxml2 dependencies. However, in
portage-2.1.7.x (current stable), there is support for
pseudo-version-ranges in dependencies. This allows you use a
dependency like <dev-lang/python-3 in a package that doesn't support
python3, and that will prevent it from getting pulled into the
dependency graph.
--
Thanks,
Zac
 
Old 03-07-2010, 04:11 PM
Mark Loeser
 
Default Python 3.1: Stabilization and news item

Sebastian Pipping <sping@gentoo.org> said:
> On 03/04/10 19:22, Arfrever Frehtes Taifersar Arahesis wrote:
> > All problems, which were blocking stabilization of Python 3, have been fixed.
> > Stabilization of Python 3.1.2 is currently scheduled on 2010-04-19.
>
> #python on Freenode still reads "It's too early to use Python 3.x".
> Are they wrong?

I'd believe them.

> Are we at a point already where we can feed 90% of the Python 2.x code
> out there to Python 3 without problems?

Doesn't seem that way.

> Has QA given their blessing to this?

Absolutely not. Its actually the opposite. Until 90+% of the tree just
works with the new version of python, it should not be stabilized. The
stable tree should all Just Work together. Stabilizing python-3 at this
point would be the equivalent of me stabilizing gcc-4.5 after its been
in the tree for a few months and nothing else works with it. Sure, gcc
works just fine, but it can't compile half of the tree.

I hope everyone can see that this is a terrible idea and of no use to
our stable users. If a stable user really needs Python-3, they will
have the technical ability to unmask it and use it properly.

--
Mark Loeser
email - halcy0n AT gentoo DOT org
email - mark AT halcy0n DOT com
web - http://www.halcy0n.com
 
Old 03-07-2010, 04:32 PM
Samuli Suominen
 
Default Python 3.1: Stabilization and news item

On 03/07/2010 07:11 PM, Mark Loeser wrote:
> Sebastian Pipping <sping@gentoo.org> said:
>> On 03/04/10 19:22, Arfrever Frehtes Taifersar Arahesis wrote:
>>> All problems, which were blocking stabilization of Python 3, have been fixed.
>>> Stabilization of Python 3.1.2 is currently scheduled on 2010-04-19.
>>
>> #python on Freenode still reads "It's too early to use Python 3.x".
>> Are they wrong?
>
> I'd believe them.
>
>> Are we at a point already where we can feed 90% of the Python 2.x code
>> out there to Python 3 without problems?
>
> Doesn't seem that way.
>
>> Has QA given their blessing to this?
>
> Absolutely not. Its actually the opposite. Until 90+% of the tree just
> works with the new version of python, it should not be stabilized. The
> stable tree should all Just Work together. Stabilizing python-3 at this
> point would be the equivalent of me stabilizing gcc-4.5 after its been
> in the tree for a few months and nothing else works with it. Sure, gcc
> works just fine, but it can't compile half of the tree.
>
> I hope everyone can see that this is a terrible idea and of no use to
> our stable users. If a stable user really needs Python-3, they will
> have the technical ability to unmask it and use it properly.
>

+1

no need to stabilize experimental python, not even convinced it should
be in ~arch yet (but package.masked for testing)
 
Old 03-07-2010, 05:25 PM
Petteri Räty
 
Default Python 3.1: Stabilization and news item

On 03/07/2010 07:11 PM, Mark Loeser wrote:
>
> Absolutely not. Its actually the opposite. Until 90+% of the tree just
> works with the new version of python, it should not be stabilized. The
> stable tree should all Just Work together. Stabilizing python-3 at this
> point would be the equivalent of me stabilizing gcc-4.5 after its been
> in the tree for a few months and nothing else works with it. Sure, gcc
> works just fine, but it can't compile half of the tree.
>

Bad analogy in my opinion. You don't really want to mix and match gcc
versions while compiling packages but with python packages you can
continue installing and running under 2* just fine. If a stable package
uses 2* it's not a blocker for 3*.

> I hope everyone can see that this is a terrible idea and of no use to
> our stable users. If a stable user really needs Python-3, they will
> have the technical ability to unmask it and use it properly.
>

In my opinion python-3 should go stable when there's enough ebuilds
needing it as a dependency. It doesn't need to nowhere near 90% of
python packages in the tree.

Regards,
Petteri
 
Old 03-07-2010, 05:26 PM
Petteri Räty
 
Default Python 3.1: Stabilization and news item

On 03/07/2010 07:32 PM, Samuli Suominen wrote:
>
> +1
>
> no need to stabilize experimental python, not even convinced it should
> be in ~arch yet (but package.masked for testing)
>

I don't think upstream considers python 3 experimental so when it can be
installed side by side with 2.6 so that ebuilds don't break it belongs
in ~arch.

Regards,
Petteri
 
Old 03-07-2010, 07:06 PM
Joshua Saddler
 
Default Python 3.1: Stabilization and news item

On Sun, 07 Mar 2010 20:26:24 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> On 03/07/2010 07:32 PM, Samuli Suominen wrote:
> > no need to stabilize experimental python, not even convinced it should
> > be in ~arch yet (but package.masked for testing)
> I don't think upstream considers python 3 experimental so when it can be
> installed side by side with 2.6 so that ebuilds don't break it belongs
> in ~arch.

Fine, then let's leave it in ~arch. Don't stabilize it yet. See below:

Mark Loeser <halcy0n@gentoo.org> wrote:
> The stable tree should all Just Work together.

That's why.
 
Old 03-08-2010, 02:08 AM
Ryan Hill
 
Default Python 3.1: Stabilization and news item

On Sun, 7 Mar 2010 12:11:47 -0500
Mark Loeser <halcy0n@gentoo.org> wrote:

> > Has QA given their blessing to this?
>
> Absolutely not. Its actually the opposite. Until 90+% of the tree just
> works with the new version of python, it should not be stabilized. The
> stable tree should all Just Work together. Stabilizing python-3 at this
> point would be the equivalent of me stabilizing gcc-4.5 after its been
> in the tree for a few months and nothing else works with it. Sure, gcc
> works just fine, but it can't compile half of the tree.

I don't think it's the same. This is like saying we can't stabilize qt-4
because half the tree is (was) qt-3. These packages are likely never going
to work with the newer version, that's why it's slotted and now we have an
admittedly impressive framework for making sure python-2 programs get
python-2 and python-3 get python-3.

Another example from my camp is wxGTK. Half the stuff in the tree (even now)
doesn't work with 2.8, so we introduced a system where packages would get the
version they needed, while users could use whatever version they wanted
independent of portage. 2.8 has been stable for over 3 years now.

I've been messing with the new python stuff this past week and I'm sold. If
you recall I was one of the people completely against the idea last time this
topic came up.

> I hope everyone can see that this is a terrible idea and of no use to
> our stable users. If a stable user really needs Python-3, they will
> have the technical ability to unmask it and use it properly.

A stable user who doesn't want python 3 installed shouldn't have it forced on
them. If something is pulling in python-3 then that package needs to have
its dependencies fixed. IIRC Portage isn't greedy wrt. SLOTs like it was
before (unless you use @installed) so it shouldn't be pulled in by anything
that doesn't require it.

Are we really saying that no python-3-based package can go into stable until
90% of the tree is python-3? That's like, 5 years from now, if ever.


--
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-08-2010, 04:00 AM
Zeerak Mustafa Waseem
 
Default Python 3.1: Stabilization and news item

On Sun, Mar 07, 2010 at 09:08:14PM -0600, Ryan Hill wrote:
> On Sun, 7 Mar 2010 12:11:47 -0500
> Mark Loeser <halcy0n@gentoo.org> wrote:
>
> > > Has QA given their blessing to this?
> >
> > Absolutely not. Its actually the opposite. Until 90+% of the tree just
> > works with the new version of python, it should not be stabilized. The
> > stable tree should all Just Work together. Stabilizing python-3 at this
> > point would be the equivalent of me stabilizing gcc-4.5 after its been
> > in the tree for a few months and nothing else works with it. Sure, gcc
> > works just fine, but it can't compile half of the tree.
>
> I don't think it's the same. This is like saying we can't stabilize qt-4
> because half the tree is (was) qt-3. These packages are likely never going
> to work with the newer version, that's why it's slotted and now we have an
> admittedly impressive framework for making sure python-2 programs get
> python-2 and python-3 get python-3.
>
> Another example from my camp is wxGTK. Half the stuff in the tree (even now)
> doesn't work with 2.8, so we introduced a system where packages would get the
> version they needed, while users could use whatever version they wanted
> independent of portage. 2.8 has been stable for over 3 years now.
>
> I've been messing with the new python stuff this past week and I'm sold. If
> you recall I was one of the people completely against the idea last time this
> topic came up.
>
> > I hope everyone can see that this is a terrible idea and of no use to
> > our stable users. If a stable user really needs Python-3, they will
> > have the technical ability to unmask it and use it properly.
>
> A stable user who doesn't want python 3 installed shouldn't have it forced on
> them. If something is pulling in python-3 then that package needs to have
> its dependencies fixed. IIRC Portage isn't greedy wrt. SLOTs like it was
> before (unless you use @installed) so it shouldn't be pulled in by anything
> that doesn't require it.
>
> Are we really saying that no python-3-based package can go into stable until
> 90% of the tree is python-3? That's like, 5 years from now, if ever.
>
>
> --
> 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


I think that is being said is, due to python 3 being unnecessary for majority of users, due to a small number of applications actually using it, it should be in ~arch. Of course an application that depends on python 3, but is entirely stable should not be marked testing (to my reckoning at least). I think the best way to go about it is to set python-3 in ~arch. As it has been said, should a user need python 3 they most likely know what they're doing and keywording it shouldn't be a problem.
So my vote goes towards stabilizing the applications that depend on python three, in their due time, and keeping python-3 keyworded.

--
Zeerak Waseem
 
Old 03-08-2010, 04:38 AM
Duncan
 
Default Python 3.1: Stabilization and news item

Petteri Räty posted on Sun, 07 Mar 2010 20:25:07 +0200 as excerpted:

> n my opinion python-3 should go stable when there's enough ebuilds
> needing it as a dependency. It doesn't need to nowhere near 90% of
> python packages in the tree.

Indeed.

Given that it's slotted and (barring bugs) won't interfere, and would need
to be stabilized before another package requiring it can be stabilized,
that would seem to be the point at which we need to worry about
stabilization -- when other package stabilization is being blocked because
they require python-3, which isn't yet stable.

But until that point... and I've seen nothing even pointed out for
discussion as an example of such a package yet... I don't see that it
needs to be (or should be) in stable at all. When such packages appear,
/then/ we can discuss if the time is right w.r.t. everything else (non-
interfering slots, etc, vs. popularity of depending package(s)). Until
then, I just don't see the purpose or point in it.

--
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-08-2010, 08:39 AM
Matti Bickel
 
Default Python 3.1: Stabilization and news item

Zeerak Mustafa Waseem wrote:
> On Sun, Mar 07, 2010 at 09:08:14PM -0600, Ryan Hill wrote:
>> A stable user who doesn't want python 3 installed shouldn't have it
>> forced on them. If something is pulling in python-3 then that
>> package needs to have its dependencies fixed. IIRC Portage isn't
>> greedy wrt. SLOTs like it was before (unless you use @installed) so
>> it shouldn't be pulled in by anything that doesn't require it.

+1 on that. If your program is only tested with python-2 or has
regressions with python-3 (e.g. performance loss), a maintainer can and
should mark that package as python-2 only. For new systems, the only
"must have" python user i can think of is portage. And that has an
explicit USE="python3" and as Zac outlined takes DEPEND-pains to ensure
python-2.* is pulled in if available. So you're starting with python-2.*
and every program not explicitly pulling in python-3.* should be happy
with that.

> I think that is being said is, due to python 3 being unnecessary for
> majority of users, due to a small number of applications actually
> using it, it should be in ~arch.

You're actually damning most of the tree to be ~arch, if that's the
criterion for stable.

> Of course an application that depends on python 3, but is entirely
> stable should not be marked testing (to my reckoning at least). I
> think the best way to go about it is to set python-3 in ~arch.

These are contradicting statements. Repoman will and should kill anyone
attempting to do that. All [R,]DEPENDS of an ebuild must be stable, if
that ebuild is to be marked stable, too.

So b/c i still can't understand what's so horrible about python-3 going
into stable (even if p.mask'ed, if that's the consensus), my vote goes
to "mark it stable already".
 

Thread Tools




All times are GMT. The time now is 07:23 AM.

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