Am 06.06.2010 08:36, schrieb Graham Murray: > Thomas Sachau <to...@gentoo.org> 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
signature.asc
Description: OpenPGP digital signature
