2011-06-27 22:57:05 Thomas Sachau napisał(a):
> Dirkjan Ochtman wrote:
> > On Mon, Jun 27, 2011 at 15:08, Fabian Groffen 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 w
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
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
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
On Tue, 28 Jun 2011 20:03:34 -0430
"Jesus Rivero (Neurogeek)" wrote:
> On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman
> 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
> >
On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman 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 there a
> number
On Tue, Jun 28, 2011 at 13:48, Jorge Manuel B. S. Vicetto
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 and don't
> "break"
-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 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 w
On Tue, 28 Jun 2011 10:04:58 +0200
Dirkjan Ochtman wrote:
> On Mon, Jun 27, 2011 at 21:31, Michał Górny 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_
On Mon, Jun 27, 2011 at 22:46, Petteri Räty 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 is able to
>
On Mon, Jun 27, 2011 at 21:31, Michał Górny 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 information is r
On Mon, Jun 27, 2011 at 20:23, Benedikt Böhm 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 this problem at
On Tue, Jun 28, 2011 at 08:54, Joshua Saddler 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 addition to 2.7.
On Mon, 27 Jun 2011 16:49:23 -0400
Mike Frysinger 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 uses it and no one
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 wrote:
> > > I like the ruby approach for the reason that it doesn't require users to
> > > run update scripts like python-updater.
>
Dirkjan Ochtman wrote:
> On Mon, Jun 27, 2011 at 15:08, Fabian Groffen 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
>> equal to one o
On Monday, June 27, 2011 12:00:19 Dirkjan Ochtman wrote:
> On Mon, Jun 27, 2011 at 17:53, Petteri Räty 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
On 27.06.2011 19:00, Dirkjan Ochtman wrote:
> On Mon, Jun 27, 2011 at 17:53, Petteri Räty 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 th
On Mon, 27 Jun 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 issu
On Mon, Jun 27, 2011 at 2:28 PM, 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?
On Mon, Jun 27, 2011 at 17:53, Petteri Räty 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 Python comes out, I'm not
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 lik
On Mon, Jun 27, 2011 at 15:08, Fabian Groffen 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 the size of
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?
Pa
Dirkjan Ochtman 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 Arfrever won'
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
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 cod
28 matches
Mail list logo
