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
On Sun, 06 Jun 2010 04:19:28 +0200
Sebastian Pipping sp...@gentoo.org wrote:
Thomas,
On 06/06/10 04:01, Thomas Sachau wrote:
[..] so even if it is not pulled in during installation, it will be
pulled in during world update.
sounds right. Preventing this requires either masking or a
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
On 06/06/2010 12:40 PM, Thomas Sachau wrote:
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,
Michał Górny wrote:
On Sun, 06 Jun 2010 04:19:28 +0200
Sebastian Pippingsp...@gentoo.org wrote:
Thomas,
On 06/06/10 04:01, Thomas Sachau wrote:
not required by any package and by default not used by
any package?
That a question I haven't seen answered before, either.
Am 06.06.2010 09:37, schrieb Michał Górny:
On Sun, 06 Jun 2010 04:19:28 +0200
Sebastian Pipping sp...@gentoo.org wrote:
Thomas,
On 06/06/10 04:01, Thomas Sachau wrote:
Since python-3* is currently useless and not required for any
package, the dependency should by default only pull in
Am 06.06.2010 13:09, schrieb Matti Bickel:
On 06/06/2010 12:40 PM, Thomas Sachau wrote:
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
Le 06/06/2010 02:08, Sebastian Pipping a écrit :
can you explain how that happens?
Standard dependency resolution for packages with slots, there's nothing
specific about python.
Cheers,
Rémi
The current python eclass also uses some vars to specify the supported slots,
yes, but it is more
complex and harder to maintain in addition to the fact, that the dependency
part is hidden from the
package manager.
I dont think, that you can tell portage with the current implementation,
Am 06.06.2010 13:50, schrieb Domen Kožar:
The current python eclass also uses some vars to specify the supported
slots, yes, but it is more
complex and harder to maintain in addition to the fact, that the dependency
part is hidden from the
package manager.
I dont think, that you can tell
Am 06.06.2010 13:50, schrieb Domen Kožar:
And if you add a python slot or remove one, portage currently is not able to
see that and to
reinstall packages, which had modules installed for that slot. You need
another tool
(python-updater) to check that and to call the needed reinstalls.
I
On Sun, 2010-06-06 at 14:41 +0200, Thomas Sachau wrote:
Am 06.06.2010 13:50, schrieb Domen Kožar:
And if you add a python slot or remove one, portage currently is not able
to see that and to
reinstall packages, which had modules installed for that slot. You need
another tool
2010-06-06 12:40:28 Thomas Sachau napisał(a):
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:
Am 06.06.2010 15:35, schrieb Domen Kožar:
On Sun, 2010-06-06 at 14:41 +0200, Thomas Sachau wrote:
Am 06.06.2010 13:50, schrieb Domen Kožar:
And if you add a python slot or remove one, portage currently is not able
to see that and to
reinstall packages, which had modules installed for that
Am 06.06.2010 15:44, schrieb Arfrever Frehtes Taifersar Arahesis:
2010-06-06 12:40:28 Thomas Sachau napisał(a):
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
2010-06-06 15:54:23 Thomas Sachau napisał(a):
Am 06.06.2010 15:44, schrieb Arfrever Frehtes Taifersar Arahesis:
2010-06-06 12:40:28 Thomas Sachau napisał(a):
Additionally, it should define the supported slots, something like this:
SUPPORTED_RUBY_SLOTS=1.8 1.9 or
On Sun, 2010-06-06 at 12:40 +0200, Thomas Sachau wrote:
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:
On Sun, Jun 06, 2010 at 01:35:55PM +, Domen Koooar wrote:
On Sun, 2010-06-06 at 14:41 +0200, Thomas Sachau wrote:
Am 06.06.2010 13:50, schrieb Domen Kožar:
And if you add a python slot or remove one, portage currently is not
able to see that and to
reinstall packages, which had
On Sun, Jun 6, 2010 at 6:54 AM, Thomas Sachau to...@gentoo.org wrote:
Am 06.06.2010 15:44, schrieb Arfrever Frehtes Taifersar Arahesis:
2010-06-06 12:40:28 Thomas Sachau napisał(a):
Additionally, it should define the supported slots, something like this:
SUPPORTED_RUBY_SLOTS=1.8 1.9 or
2010-05-27 16:33:39 Thomas Sachau napisał(a):
Hi together,
since i am not able to get any real argument or even discussion on IRC nor on
this mailing list from
Arfrever (main person behind those changes), i would like to raise the
following points now on this
mailing list as told on IRC,
Am 05.06.2010 16:43, schrieb Arfrever Frehtes Taifersar Arahesis:
2010-05-27 16:33:39 Thomas Sachau napisał(a):
Hi together,
since i am not able to get any real argument or even discussion on IRC nor
on this mailing list from
Arfrever (main person behind those changes), i would like to
On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote:
If any package does inherit python or distutils eclass, then those eclasses
do pull in
dev-lang/python, which is unversioned, so it will always pull in the latest
version, in this case
python-3*. You could change this, so it
Thomas, Arfrever,
the way this discussion currently works does not look fruitful to me.
Questions I would like to raise:
- How come you don't agree on facts?
- Is this about processes or results?
- Have you tried to understand the other side's problem?
- Could you try a
Am 05.06.2010 20:31, schrieb Harald van Dijk:
On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote:
If any package does inherit python or distutils eclass, then those eclasses
do pull in
dev-lang/python, which is unversioned, so it will always pull in the
latest version, in this
On Sun, Jun 06, 2010 at 01:03:48AM +0200, Thomas Sachau wrote:
Am 05.06.2010 20:31, schrieb Harald van Dijk:
On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote:
If any package does inherit python or distutils eclass, then those
eclasses do pull in
dev-lang/python, which is
Thomas,
On 06/06/10 01:04, Thomas Sachau wrote:
Every slot and every version *should* satisfy a dev-lang/python dependency,
but currently such
unspecified version dependency does automaticly pull in the latest
version/slot, which in case of
python does mean python-3*, even when you have
Am 06.06.2010 01:38, schrieb Harald van Dijk:
On Sun, Jun 06, 2010 at 01:03:48AM +0200, Thomas Sachau wrote:
Am 05.06.2010 20:31, schrieb Harald van Dijk:
On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote:
If any package does inherit python or distutils eclass, then those
eclasses
Thomas,
On 06/06/10 04:01, Thomas Sachau wrote:
[..] so even if it is not pulled in during installation, it will be pulled in
during world update.
sounds right. Preventing this requires either masking or a
dont-pull-uninstalled-slots switch for portage (which I am not
suggesting), right?
Hi together,
since i am not able to get any real argument or even discussion on IRC nor on
this mailing list from
Arfrever (main person behind those changes), i would like to raise the
following points now on this
mailing list as told on IRC, so he gets the chance to answer those points and
to
Le jeudi 27 mai 2010 à 16:33 +0200, Thomas Sachau a écrit :
Hi together,
since i am not able to get any real argument or even discussion on IRC nor on
this mailing list from
Arfrever (main person behind those changes), i would like to raise the
following points now on this
mailing list
30 matches
Mail list logo
