| 1 |
On Fri, Mar 19, 2010 at 8:13 AM, Nikos Chantziaras <realnc@×××××.de> wrote: |
| 2 |
> On 03/19/2010 10:57 AM, Ciaran McCreesh wrote: |
| 3 |
>> |
| 4 |
>> On Fri, 19 Mar 2010 03:54:28 -0500 |
| 5 |
>> Dale<rdalek1967@×××××.com> wrote: |
| 6 |
>>> |
| 7 |
>>> Ciaran McCreesh wrote: |
| 8 |
>>>> |
| 9 |
>>>> On Thu, 18 Mar 2010 23:17:17 +0100 |
| 10 |
>>>> Ben de Groot<yngwin@g.o> wrote: |
| 11 |
>>>> |
| 12 |
>>>>> Because it is extremely useless to the great majority of users. |
| 13 |
>>>>> |
| 14 |
>>>> Most packages in the tree are useless to the great majority of |
| 15 |
>>>> users. |
| 16 |
>>> |
| 17 |
>>> Which is why most users don't install everything. I have about 1000 |
| 18 |
>>> packages installed here. The packages installed are either something |
| 19 |
>>> I use or a dependency of something I use. What exactly is this being |
| 20 |
>>> installed for again? If nothing depends on it, there is no need to |
| 21 |
>>> have it. |
| 22 |
>> |
| 23 |
>> It's being installed because it's a dependency of something you use. |
| 24 |
>> |
| 25 |
>> Replace Python with any other library and we wouldn't be having this |
| 26 |
>> discussion. |
| 27 |
> |
| 28 |
> It's weird that we have this discussion, that's true. Why don't you guys |
| 29 |
> simply do what you did before when Qt3 was still in the tree? Qt3 |
| 30 |
> applications depended on x11-libs/qt:3, Qt4 ones on x11-libs/qt:4 (before |
| 31 |
> the Qt4 ebuild split). |
| 32 |
|
| 33 |
Using your example, some applications would have had to exist that |
| 34 |
could use either Qt3 or Qt4, so a greedy SLOT matcher would pull in |
| 35 |
Qt4 (and to be equal to the python case, portage would have to build |
| 36 |
two copies of all the binaries, one linked against qt3 and one linked |
| 37 |
against qt4, because python.eclass does something similar, but I |
| 38 |
digress.) |
| 39 |
|
| 40 |
> |
| 41 |
> It seems very obvious and straightforward that the same applies here. And if |
| 42 |
> a package offers both Python 2 and Python 3 compatibility, it should depend |
| 43 |
> on whatever the upstream of that package considers best. |
| 44 |
|
| 45 |
When choosing dependencies you want to maximize flexibility (because |
| 46 |
users like it for some reason). So we chose 'dev-lang/python' because |
| 47 |
typically any ole' version of python will work. If we hardcoded |
| 48 |
everything upstream 'recommended' (many upstreams don't make such |
| 49 |
recommendations either, which puts us in an interesting situation) it |
| 50 |
means when our users want to do something upstream does not |
| 51 |
'recommend' they have to do a bunch of work like have a custom overlay |
| 52 |
just so they can changed a DEPEND string that should not have been so |
| 53 |
specific in the first place. |
| 54 |
|
| 55 |
Amusingly this very thing happened to me at work; a bunch of scripts |
| 56 |
depend on python but their dependencies are 'python2.4' and Ubuntu |
| 57 |
Lucid has no python2.4 (it ships with 2.6). Now I get to rewrite all |
| 58 |
the dependencies in all the debs to depend on 'python < 3' instead of |
| 59 |
'python2.4.' Most of this work would have been unnecessary had the |
| 60 |
dependencies just been a bit more flexible. |
| 61 |
|
| 62 |
> |
| 63 |
> Also, we had a "qt" and "qt4" USE flag before. Why not "python" and |
| 64 |
> "python3" flags? That's an additional way ebuilds can choose deps. |
| 65 |
> |
| 66 |
> You guys always make easy decisions so complicated. :P |
| 67 |
|
| 68 |
Masking a package is not complicated. |
| 69 |
|
| 70 |
> |
| 71 |
> |
| 72 |
> |
| 73 |
|
| 74 |
I just want to give props to Arfrever for getting Python3 into the |
| 75 |
tree so quickly. Thanks for all your work on this. |
| 76 |
|
| 77 |
-A |
Archives