Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*

[Thomas Sachau]

Am 06.06.2010 08:36, schrieb Graham Murray:
> Thomas Sachau <tommy@g.o> writes:
>
>> Since python-3* is currently useless and not required for any package, the dependency should by
>> default only pull in python-2* like this:
>>
>> =dev-lang/python-2*
>>
>> With that, the default way would not pull in a package, which is not needed or used. And if there
>> will be any package, which really requires python-3*, it simply requests it in (R)DEPEND of the
>> ebuild, which then would overwrite the default value of the eclass and pull in python-3*.
>
> That would not work. For example if package 'bar' supports both python-2
> and python-3, your mechanism will only build in python-2 support. That
> is fine until package 'foo' comes along which uses 'bar' but also
> requires python-3 - thus not only must python-3 be pulled in as a result
> of foo's (R)DEPEND but also 'bar' must be rebuilt with python-3 support.

And that is, how it should be done. Think for example of a package foo, which has a "png" USE flag,
which will pull in libpng. By default disabled, it results in disabled png support and libpng not
pulled in. Now, when some other package requires foo with png USE flag enabled, you will have to
recompile foo with png USE flag and you will have to install libpng. We have the usedeps of EAPI-2
for it and the package manager does handle it, depending on the user requests.

But for optional python-3 support, you cannot control it easily with your package manager because of
the current way, how it is implemented.

>
> This could be done by adding python2 and python3 USE flags to packages
> which support both and only have python2 enabled by default. Then 'foo'
> could have a conditional (R)DEPEMD on 'bar[python3]', but that would
> require the user to change the USE flags whereas the current system
> handles everything automatically.

And automagic behind the scene is exactly, what should not happen. The user should be able to
control optional dependencies, it should be the same for python like for any other package.

My base proposal for this is something like this:

Every package defines the language(s), where it could be installed for multiple slots, e.g.:

MULTI_SLOT="python" or
MULTI_SLOT="python ruby"

Additionally, it should define the supported slots, something like this:

SUPPORTED_RUBY_SLOTS="1.8 1.9" or
SUPPORTED_PYTHON_SLOTS="2.5 2.6 3.0 3.1"

Now the package manager should take those vars and convert them to some expanded USE vars like:

RUBY_SLOTS="1.8 1.9" or
PYTHON_SLOTS="2.5 2.6 3.0 3.1"

By default, the current active version should be enabled, the others disabled. In addition, every
dependency, which requires ruby/python should get internal usedeps, so that they require the same
slots as this package. Every enabled slot should of course pull in that slot of the language.

With this way, every user can select, which slots he wants to use and which slots should be
installed. And if any package requires an installed version for a specific slot, it can be set in
(R)DEPEND (e.g. like DEPEND=" python? ( dev-db/foo[pyhon_slot_2.6] )")

It would also reduce the amount of code, since we would not have to implement multi-slot support in
many different eclasses and it would additionally move the dependency control back to the package
manager unlike the current python implementation.

I currently have a branch of portage ("multilib-portage"), which can install a package for different
platforms, it could be extended to implement the above idea and i plan to do that. Since i am the
only person working on it and me only having limited time and knowledge, it could still take some
time, if noone else wants to step in and help with it.

-- 
Thomas Sachau

Gentoo Linux Developer