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 Tue, 28 Jun 2011 10:16:06 +0400
Peter Volkov wrote:
> But still our documentation explicitly suggests ':' for CFLAGS cases
> and example allows bash substitution.
>
> http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building/index.html
> see example in "Fixing Compiler Usage"
On 28-06-2011 10:16:06 +0400, Peter Volkov wrote:
> Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see
> attachment)?
Not from my side. It's what we've been using so far.
>
> -When using sed with CFLAGS or LDFLAGS, it is not safe
> to use
> -a comma or a slash as a delimiter. Th
On Mon, 27 Jun 2011 20:21:29 +0200
Maciej Mrozowski wrote:
> > The problems with PROPERTIES=set remain exactly the same as they
> > were when it was first proposed.
>
> Which is?
> No, "been there, done that, won't work" is not sufficient. Please
> elaborate.
You can find and read the original d
On Mon, 27 Jun 2011 16:23:54 -0400
Rich Freeman wrote:
> Sets should really be something carefully controlled by the
> repository. While I'm fine with having tags in the repository also,
> there is talk about giving users ways of supplying them as well.
Why? You can have carefully controlled set
On Tue, 28 Jun 2011 16:54:43 +1200
Kent Fredric wrote:
> Reminds me of the other awkward behaviour I once hit where a package
> depends on something that is slotted, and mysteriously uses a middle
> version of the things that are slotted, and then breaks with that
> version that it for some myster
В Пнд, 27/06/2011 в 17:01 +0200, Fabian Groffen пишет:
> On 27-06-2011 14:08:52 +, Justin Lecher wrote:
> > Please do not use / as seperater when using sed with CFLAGS. I came
> across a bug today where it failed for crossdev. Here the toolchain
> header paths in the cflags and consowuently the
On 28 June 2011 04:44, Graham Murray wrote:
> Ciaran McCreesh writes:
>
>> The fix for that is to slot things properly. You're screwed anyway if a
>> preserved library tries to access installed data that has either been
>> removed or upgraded to a new format that it doesn't recognise.
>
> Or some
On 28 June 2011 15:26, Brian Harring wrote:
> This is a bit inverted- tagging is fundamentally pkg specific. If we
> did as you proposed and I wanted to find out all tags/descriptions for
> a pkg, the PM would have to scan every tags file there.
>
> Additionally, as others have indicated, it suck
On Sun, Jun 26, 2011 at 08:02:57AM +0100, Ciaran McCreesh wrote:
> Here's a completely different way of doing tags:
>
> First, standardise sets. We probably want to go with a format along the
> lines of:
>
> eapi = 4
> description = Monkeys
>
> dev-monkey/howler
> dev-monkey/spid
On 06/27/2011 07:23 AM, Jesús J. Guerrero Botella wrote:
> I still don't understand why
>
> A) you need to build a project, a glep, whatever the course of action
> is, I am bad at bureaucracy.
> B) you need to code the solution, to fix What?
Some people requested a "tags" feature. I'm not sure if
On Sunday, June 26, 2011 12:51:53 Nirbheek Chauhan wrote:
> On Sun, Jun 26, 2011 at 9:45 PM, Mike Frysinger wrote:
> > On Sat, Jun 25, 2011 at 13:51, Nirbheek Chauhan wrote:
> >> On Sat, Jun 25, 2011 at 10:54 PM, Mike Frysinger wrote:
> >>> On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
> >
2011/6/27 Wyatt Epp :
> 2011/6/27 Jesús J. Guerrero Botella :
>> That still doesn't answer my question anyway: both features (symlinks
>> and +65k files on a single dir) are incompatible with fat32. And
>> someone said fat32 compatibility is a feature we want (still can't
>> guess why, but well, be
On Mon, Jun 27, 2011 at 17:23, Rich Freeman wrote:
> That wasn't what I was thinking of. Package masking is also something
> we carefully control in the repository but users can override it FOR
> THEIR OWN SYSTEMS. With tags I think that there were concepts
> floating around of letting anybody i
On Mon, Jun 27, 2011 at 5:06 PM, Wyatt Epp wrote:
> On Mon, Jun 27, 2011 at 16:23, Rich Freeman wrote:
>> I too feel that tags should be distinct from sets, for a bunch of reasons.
>>
>> Sets should really be something carefully controlled by the
>> repository. While I'm fine with having tags in
On Mon, Jun 27, 2011 at 16:23, Rich Freeman wrote:
> I too feel that tags should be distinct from sets, for a bunch of reasons.
>
> Sets should really be something carefully controlled by the
> repository. While I'm fine with having tags in the repository also,
> there is talk about giving users
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 Monday, June 27, 2011 15:56:24 justin wrote:
> On 6/27/11 9:26 PM, Mike Frysinger wrote:
> > On Monday, June 27, 2011 11:23:58 Lars Wendler wrote:
> >> Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen:
> >>> On 27-06-2011 14:08:52 +, Justin Lecher wrote:
> Please do not use / as
On Mon, Jun 27, 2011 at 1:49 AM, Ciaran McCreesh
wrote:
> On Sun, 26 Jun 2011 17:12:27 +0200
> Maciej Mrozowski wrote:
>
>> Sets concept is completely orthogonal to tags concept, please do not
>> mix unrelated things.
>
> Depends upon what you think the "tags concept" is. We've already
> establis
On 6/27/11 9:26 PM, Mike Frysinger wrote:
> On Monday, June 27, 2011 11:23:58 Lars Wendler wrote:
>> Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen:
>>> On 27-06-2011 14:08:52 +, Justin Lecher wrote:
Please do not use / as seperater when using sed with CFLAGS. I came
across a
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 Monday, June 27, 2011 11:23:58 Lars Wendler wrote:
> Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen:
> > On 27-06-2011 14:08:52 +, Justin Lecher wrote:
> > > Please do not use / as seperater when using sed with CFLAGS. I came
> > > across a bug today where it failed for crossdev. He
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 Monday 27 of June 2011 07:49:24 Ciaran McCreesh wrote:
> On Sun, 26 Jun 2011 17:12:27 +0200
> Maciej Mrozowski wrote:
> > On Sunday 26 of June 2011 09:02:57 Ciaran McCreesh wrote:
> > > Here's a completely different way of doing tags:
> > As far as sets are concerned, how about PROPERTIES=set?
Jesús J. Guerrero Botella posted on Mon, 27 Jun 2011 16:19:57 +0200 as
excerpted:
> someone said fat32 compatibility is a feature we want (still can't guess
> why, but well, be consequent...).
I believe that "someone" that mentioned fat32 compatibility in the
context of symlinks was me.
But "
2011/6/27 Jesús J. Guerrero Botella :
> That still doesn't answer my question anyway: both features (symlinks
> and +65k files on a single dir) are incompatible with fat32. And
> someone said fat32 compatibility is a feature we want (still can't
> guess why, but well, be consequent...). Obviously,
Ciaran McCreesh writes:
> The fix for that is to slot things properly. You're screwed anyway if a
> preserved library tries to access installed data that has either been
> removed or upgraded to a new format that it doesn't recognise.
Or some "awkward" packages which when rebuilt will still link
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, 27 Jun 2011 17:01:01 +0200
Fabian Groffen wrote:
> On 27-06-2011 14:08:52 +, Justin Lecher wrote:
> > Please do not use / as seperater when using sed with CFLAGS. I came
> > across a bug today where it failed for crossdev. Here the toolchain
> > header paths in the cflags and consowue
On 17:23 Mon 27 Jun , Lars Wendler wrote:
> Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen:
> > On 27-06-2011 14:08:52 +, Justin Lecher wrote:
> > > Please do not use / as seperater when using sed with CFLAGS. I came
> > > across a bug today where it failed for crossdev. Here the t
Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen:
> On 27-06-2011 14:08:52 +, Justin Lecher wrote:
> > Please do not use / as seperater when using sed with CFLAGS. I came
> > across a bug today where it failed for crossdev. Here the toolchain
> > header paths in the cflags and consowuent
On 27-06-2011 14:08:52 +, Justin Lecher wrote:
> Please do not use / as seperater when using sed with CFLAGS. I came across a
> bug today where it failed for crossdev. Here the toolchain header paths in
> the cflags and consowuently the seds fail.
Please also don't use ':' as separator, as s
2011/6/27 Zac Medico :
> On 06/24/2011 12:52 AM, Jesús J. Guerrero Botella wrote:
>> 2011/6/24 Zac Medico :
>>> On 06/22/2011 11:15 PM, Jesús J. Guerrero Botella wrote:
Symlinks are clean, and portage has
always been file-oriented so I see no problem with using them for
this. All we
2011/6/26 Kent Fredric :
> 2011/6/26 Jesús J. Guerrero Botella :
>> I am really amazed that someone didn't want to use links (a solution
>> with next to zero work involved) because they are not available in
>> fat32 (as if fat32 was relevant at all for us) but then people is
>> suggesting that we s
Hi
Please do not use / as seperater when using sed with CFLAGS. I came across a
bug today where it failed for crossdev. Here the toolchain header paths in the
cflags and consowuently the seds fail.
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
45 matches
Mail list logo
