Am Mittwoch, 29. Juni 2011, 06:34:52 schrieb Michał Górny:
As I said it already, we could start doing things simpler in the
current python.eclass and maybe that would attract some devs to help
out with it, as they find it more comfortable to work with.
I think it would be better to
El mié, 29-06-2011 a las 09:18 +0200, Andreas K. Huettel escribió:
Am Mittwoch, 29. Juni 2011, 06:34:52 schrieb Michał Górny:
As I said it already, we could start doing things simpler in the
current python.eclass and maybe that would attract some devs to help
out with it, as they find
2011-06-29 02:33:34 Jesus Rivero (Neurogeek) napisał(a):
With python-updater, well, some time ago Ali Polatel implemented some
approaches to get rid of python-updater, by exporting some variable in
ebuilds that needed to be rebuilt when new python versions were
installed. I dont recall what
2011-06-27 22:57:05 Thomas Sachau napisał(a):
Dirkjan Ochtman wrote:
On Mon, Jun 27, 2011 at 15:08, Fabian Groffen grob...@gentoo.org wrote:
On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote:
It would be nice when a similar technique could be implemented only
once, in a consistent way.
On Mon, 27 Jun 2011 16:49:23 -0400
Mike Frysinger vap...@gentoo.org wrote:
if you dont want multiple builds on your system, then dont install
multiple versions of python.
-mike
This would be nice, but unfortunately the python maintainer forced
3.x on everyone, despite the fact that nothing
On Tue, Jun 28, 2011 at 08:54, Joshua Saddler nightmo...@gentoo.org wrote:
This would be nice, but unfortunately the python maintainer forced
3.x on everyone, despite the fact that nothing uses it and no one
really wanted it made the default. So now it's shipped with all the
stage tarballs, in
On Mon, Jun 27, 2011 at 20:23, Benedikt Böhm hol...@gentoo.org wrote:
the way python applications are built currently renders all binary
packages useless, since portage does not know which version of python
it was built against. the explicit selection with RUBY_TARGETS or
PHP_TARGETS solves
On Mon, Jun 27, 2011 at 21:31, Michał Górny mgo...@gentoo.org wrote:
Working targets. USE_PYTHON is junk. What python.eclass does now with
ABIs is a PITA, and requires manually providing a lot of redudant
information (namely, RESTRICT_PYTHON_ABIS).
Please clarify *why* it is a PITA, and what
On Mon, Jun 27, 2011 at 22:46, Petteri Räty betelge...@gentoo.org wrote:
Sure, but if that means the developers now have to bump every package
in the tree when a new version of Python comes out, I'm not sure
that's the best trade-off.
And why can't this be handled by the eclass? If the ebuild
On Tue, 28 Jun 2011 10:04:58 +0200
Dirkjan Ochtman d...@gentoo.org wrote:
On Mon, Jun 27, 2011 at 21:31, Michał Górny mgo...@gentoo.org wrote:
Working targets. USE_PYTHON is junk. What python.eclass does now
with ABIs is a PITA, and requires manually providing a lot of
redudant information
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28-06-2011 07:19, Dirkjan Ochtman wrote:
On Tue, Jun 28, 2011 at 08:54, Joshua Saddler nightmo...@gentoo.org wrote:
This would be nice, but unfortunately the python maintainer forced
3.x on everyone, despite the fact that nothing uses it and
On Tue, Jun 28, 2011 at 13:48, Jorge Manuel B. S. Vicetto
jmbsvice...@gentoo.org wrote:
Yes, but with slotting you allow different packages to pull in different
slots of python. Furthermore, when you slot a package and mark more than
one slot stable, you're saying that all the stable slots work
On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman d...@gentoo.org wrote:
Hi guys,
[...]
So I know a bunch of people have already looked at it, and I'd like to
know: what do you find better about the Ruby approach compared to the
Python approach? Is it just the size of python.eclass, or are
On Tue, 28 Jun 2011 20:03:34 -0430
Jesus Rivero (Neurogeek) neurog...@gentoo.org wrote:
On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman d...@gentoo.org
wrote:
Hi guys,
[...]
So I know a bunch of people have already looked at it, and I'd like
to know: what do you find better about the
Hi guys,
I guess by now pretty much everyone knows that the python eclass is
rather complex, and that this poses some problems. This has also been
an important cause for the disagreements between Arfrever and some of
the other developers. Since it appears that Arfrever won't be
committing much
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Dirkjan Ochtman d...@gentoo.org writes:
I guess by now pretty much everyone knows that the python eclass is
rather complex, and that this poses some problems. This has also been
an important cause for the disagreements between Arfrever and some of
the other developers. Since it appears that
On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote:
So I know a bunch of people have already looked at it, and I'd like to
know: what do you find better about the Ruby approach compared to the
Python approach? Is it just the size of python.eclass, or are there a
number of other issues?
Part
On Mon, Jun 27, 2011 at 15:08, Fabian Groffen grob...@gentoo.org wrote:
On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote:
So I know a bunch of people have already looked at it, and I'd like to
know: what do you find better about the Ruby approach compared to the
Python approach? Is it just
On 27.06.2011 15:28, Dirkjan Ochtman wrote:
So I know a bunch of people have already looked at it, and I'd like to
know: what do you find better about the Ruby approach compared to the
Python approach? Is it just the size of python.eclass, or are there a
number of other issues?
I like the
On Mon, Jun 27, 2011 at 17:53, Petteri Räty betelge...@gentoo.org wrote:
I like the ruby approach for the reason that it doesn't require users to
run update scripts like python-updater.
Sure, but if that means the developers now have to bump every package
in the tree when a new version of
On Mon, Jun 27, 2011 at 2:28 PM, Dirkjan Ochtman d...@gentoo.org wrote:
So I know a bunch of people have already looked at it, and I'd like to
know: what do you find better about the Ruby approach compared to the
Python approach? Is it just the size of python.eclass, or are there a
number of
On Mon, 27 Jun 2011 14:28:34 +0200
Dirkjan Ochtman d...@gentoo.org wrote:
So I know a bunch of people have already looked at it, and I'd like to
know: what do you find better about the Ruby approach compared to the
Python approach? Is it just the size of python.eclass, or are there a
number
On 27.06.2011 19:00, Dirkjan Ochtman wrote:
On Mon, Jun 27, 2011 at 17:53, Petteri Räty betelge...@gentoo.org wrote:
I like the ruby approach for the reason that it doesn't require users to
run update scripts like python-updater.
Sure, but if that means the developers now have to bump every
On Monday, June 27, 2011 09:43:05 Dirkjan Ochtman wrote:
On Mon, Jun 27, 2011 at 15:08, Fabian Groffen wrote:
It would be nice when a similar technique could be implemented only
once, in a consistent way. In a way, multilib-portage can be considered
equal to one of the objectives of the
On Monday, June 27, 2011 12:00:19 Dirkjan Ochtman wrote:
On Mon, Jun 27, 2011 at 17:53, Petteri Räty betelge...@gentoo.org wrote:
I like the ruby approach for the reason that it doesn't require users to
run update scripts like python-updater.
Sure, but if that means the developers now have
Dirkjan Ochtman wrote:
On Mon, Jun 27, 2011 at 15:08, Fabian Groffen grob...@gentoo.org wrote:
On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote:
It would be nice when a similar technique could be implemented only
once, in a consistent way. In a way, multilib-portage can be considered
On Mon, 2011-06-27 at 16:52 -0400, Mike Frysinger wrote:
On Monday, June 27, 2011 12:00:19 Dirkjan Ochtman wrote:
On Mon, Jun 27, 2011 at 17:53, Petteri Räty betelge...@gentoo.org wrote:
I like the ruby approach for the reason that it doesn't require users to
run update scripts like
28 matches
Mail list logo
