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 {}.
27 matches
Mail list logo
