1 |
On Mon, Jul 30, 2012 at 11:40 AM, Dirkjan Ochtman <djc@g.o> wrote: |
2 |
> On Mon, Jul 30, 2012 at 5:30 PM, Mike Gilbert <floppym@g.o> wrote: |
3 |
>>> I guess I still think it should be possible to give Portage a hint not |
4 |
>>> to install a new SLOT if the old SLOT is okay. |
5 |
>> |
6 |
>> In this case, I think we would need something more subtle than that; |
7 |
>> most users would want a hypothetical python-2.8 to be installed, and |
8 |
>> python-3 users will certainly want to be upgraded to python-3.3 when |
9 |
>> that lands. |
10 |
>> |
11 |
>> In other words, if we tell portage not to upgrade to a new slot |
12 |
>> automatically, that means users would have to manually install each |
13 |
>> major release of python. |
14 |
> |
15 |
> No, I was going for the kind of effect where being inclusive wrt the |
16 |
> new major Python version would be controlled in a single place. I.e. |
17 |
> in the ebuild or in an eclass or some such. |
18 |
> |
19 |
> So you'd have SLOT="~3" in the python-3* ebuilds, and Portage would |
20 |
> know to not install SLOT=3 unless requested explicitly, and at some |
21 |
> point we'd remove the '~'. |
22 |
|
23 |
Where else in the tree could this concept be applied? |
24 |
|
25 |
I would prefer to avoid going through the EAPI process if it is just |
26 |
going to be used for python. And even then, I'm not really excited |
27 |
about the prospect of explaining it. |
28 |
|
29 |
Also, I'm sure that people will whine about the "upgrade path" being |
30 |
broken if we set EAPI=5 or 6 in the python ebuilds any time this |
31 |
decade. |
32 |
|
33 |
A solution that works within the confines of the current EAPI spec |
34 |
should be greatly preferred. |