On Fri, Mar 19, 2010 at 8:13 AM, Nikos Chantziaras <rea...@arcor.de> wrote:
> On 03/19/2010 10:57 AM, Ciaran McCreesh wrote:
>>
>> On Fri, 19 Mar 2010 03:54:28 -0500
>> Dale<rdalek1...@gmail.com>  wrote:
>>>
>>> Ciaran McCreesh wrote:
>>>>
>>>> On Thu, 18 Mar 2010 23:17:17 +0100
>>>> Ben de Groot<yng...@gentoo.org>   wrote:
>>>>
>>>>> Because it is extremely useless to the great majority of users.
>>>>>
>>>> Most packages in the tree are useless to the great majority of
>>>> users.
>>>
>>> Which is why most users don't install everything.  I have about 1000
>>> packages installed here.  The packages installed are either something
>>> I use or a dependency of something I use.  What exactly is this being
>>> installed for again?  If nothing depends on it, there is no need to
>>> have it.
>>
>> It's being installed because it's a dependency of something you use.
>>
>> Replace Python with any other library and we wouldn't be having this
>> discussion.
>
> It's weird that we have this discussion, that's true.  Why don't you guys
> simply do what you did before when Qt3 was still in the tree?  Qt3
> applications depended on x11-libs/qt:3, Qt4 ones on x11-libs/qt:4 (before
> the Qt4 ebuild split).

Using your example, some applications would have had to exist that
could use either Qt3 or Qt4, so a greedy SLOT matcher would pull in
Qt4 (and to be equal to the python case, portage would have to build
two copies of all the binaries, one linked against qt3 and one linked
against qt4, because python.eclass does something similar, but I
digress.)

>
> It seems very obvious and straightforward that the same applies here. And if
> a package offers both Python 2 and Python 3 compatibility, it should depend
> on whatever the upstream of that package considers best.

When choosing dependencies you want to maximize flexibility (because
users like it for some reason).  So we chose 'dev-lang/python' because
typically any ole' version of python will work.  If we hardcoded
everything upstream 'recommended' (many upstreams don't make such
recommendations either, which puts us in an interesting situation) it
means when our users want to do something upstream does not
'recommend' they have to do a bunch of work like have a custom overlay
just so they can changed a DEPEND string that should not have been so
specific in the first place.

Amusingly this very thing happened to me at work; a bunch of scripts
depend on python but their dependencies are 'python2.4' and Ubuntu
Lucid has no python2.4 (it ships with 2.6). Now I get to rewrite all
the dependencies in all the debs to depend on 'python < 3' instead of
'python2.4.'  Most of this work would have been unnecessary had the
dependencies just been a bit more flexible.

>
> Also, we had a "qt" and "qt4" USE flag before.  Why not "python" and
> "python3" flags?  That's an additional way ebuilds can choose deps.
>
> You guys always make easy decisions so complicated. :P

Masking a package is not complicated.

>
>
>

I just want to give props to Arfrever for getting Python3 into the
tree so quickly.  Thanks for all your work on this.

-A

Reply via email to