| 1 |
On Sun, Mar 07, 2010 at 09:08:14PM -0600, Ryan Hill wrote: |
| 2 |
> On Sun, 7 Mar 2010 12:11:47 -0500 |
| 3 |
> Mark Loeser <halcy0n@g.o> wrote: |
| 4 |
> |
| 5 |
> > > Has QA given their blessing to this? |
| 6 |
> > |
| 7 |
> > Absolutely not. Its actually the opposite. Until 90+% of the tree just |
| 8 |
> > works with the new version of python, it should not be stabilized. The |
| 9 |
> > stable tree should all Just Work together. Stabilizing python-3 at this |
| 10 |
> > point would be the equivalent of me stabilizing gcc-4.5 after its been |
| 11 |
> > in the tree for a few months and nothing else works with it. Sure, gcc |
| 12 |
> > works just fine, but it can't compile half of the tree. |
| 13 |
> |
| 14 |
> I don't think it's the same. This is like saying we can't stabilize qt-4 |
| 15 |
> because half the tree is (was) qt-3. These packages are likely never going |
| 16 |
> to work with the newer version, that's why it's slotted and now we have an |
| 17 |
> admittedly impressive framework for making sure python-2 programs get |
| 18 |
> python-2 and python-3 get python-3. |
| 19 |
> |
| 20 |
> Another example from my camp is wxGTK. Half the stuff in the tree (even now) |
| 21 |
> doesn't work with 2.8, so we introduced a system where packages would get the |
| 22 |
> version they needed, while users could use whatever version they wanted |
| 23 |
> independent of portage. 2.8 has been stable for over 3 years now. |
| 24 |
> |
| 25 |
> I've been messing with the new python stuff this past week and I'm sold. If |
| 26 |
> you recall I was one of the people completely against the idea last time this |
| 27 |
> topic came up. |
| 28 |
> |
| 29 |
> > I hope everyone can see that this is a terrible idea and of no use to |
| 30 |
> > our stable users. If a stable user really needs Python-3, they will |
| 31 |
> > have the technical ability to unmask it and use it properly. |
| 32 |
> |
| 33 |
> A stable user who doesn't want python 3 installed shouldn't have it forced on |
| 34 |
> them. If something is pulling in python-3 then that package needs to have |
| 35 |
> its dependencies fixed. IIRC Portage isn't greedy wrt. SLOTs like it was |
| 36 |
> before (unless you use @installed) so it shouldn't be pulled in by anything |
| 37 |
> that doesn't require it. |
| 38 |
> |
| 39 |
> Are we really saying that no python-3-based package can go into stable until |
| 40 |
> 90% of the tree is python-3? That's like, 5 years from now, if ever. |
| 41 |
> |
| 42 |
> |
| 43 |
> -- |
| 44 |
> fonts, by design, by neglect |
| 45 |
> gcc-porting, for a fact or just for effect |
| 46 |
> wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |
| 47 |
|
| 48 |
|
| 49 |
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. |
| 50 |
So my vote goes towards stabilizing the applications that depend on python three, in their due time, and keeping python-3 keyworded. |
| 51 |
|
| 52 |
-- |
| 53 |
Zeerak Waseem |
Archives