1 |
On Mon, Jul 30, 2012 at 10:56 AM, Mike Gilbert <floppym@g.o> wrote: |
2 |
> On Mon, Jul 30, 2012 at 11:40 AM, Dirkjan Ochtman <djc@g.o> wrote: |
3 |
>> On Mon, Jul 30, 2012 at 5:30 PM, Mike Gilbert <floppym@g.o> wrote: |
4 |
>>>> I guess I still think it should be possible to give Portage a hint not |
5 |
>>>> to install a new SLOT if the old SLOT is okay. |
6 |
>>> |
7 |
>>> In this case, I think we would need something more subtle than that; |
8 |
>>> most users would want a hypothetical python-2.8 to be installed, and |
9 |
>>> python-3 users will certainly want to be upgraded to python-3.3 when |
10 |
>>> that lands. |
11 |
>>> |
12 |
>>> In other words, if we tell portage not to upgrade to a new slot |
13 |
>>> automatically, that means users would have to manually install each |
14 |
>>> major release of python. |
15 |
>> |
16 |
>> No, I was going for the kind of effect where being inclusive wrt the |
17 |
>> new major Python version would be controlled in a single place. I.e. |
18 |
>> in the ebuild or in an eclass or some such. |
19 |
>> |
20 |
>> So you'd have SLOT="~3" in the python-3* ebuilds, and Portage would |
21 |
>> know to not install SLOT=3 unless requested explicitly, and at some |
22 |
>> point we'd remove the '~'. |
23 |
> |
24 |
> Where else in the tree could this concept be applied? |
25 |
> |
26 |
> I would prefer to avoid going through the EAPI process if it is just |
27 |
> going to be used for python. And even then, I'm not really excited |
28 |
> about the prospect of explaining it. |
29 |
> |
30 |
> Also, I'm sure that people will whine about the "upgrade path" being |
31 |
> broken if we set EAPI=5 or 6 in the python ebuilds any time this |
32 |
> decade. |
33 |
> |
34 |
> A solution that works within the confines of the current EAPI spec |
35 |
> should be greatly preferred. |
36 |
> |
37 |
|
38 |
Could we not just set a dep as =dev-lang/python:2 so that any version |
39 |
of python-2.* would satisfy the dep? Or, would this cause issues in |
40 |
avoiding old versions of python (python-2.5)? It might be enough to |
41 |
change the portage ebuild to work as it does now for the USE python2 |
42 |
and python3, but in the case where those flags are not set, then just |
43 |
pull in python:2 which would yield the latest stable version of |
44 |
python-2.* |
45 |
|
46 |
I think adding something to EAPI is going to take too long and/or not |
47 |
work well for folks. |
48 |
|
49 |
For python-updater, I might be inclined to add similar USE to portage |
50 |
to manage the deps. |
51 |
|
52 |
-- |
53 |
Matthew W. Summers |
54 |
Gentoo Foundation Inc. |