Hi,
Christopher Swift :
> If possible I'd like to contribute to this herd, I have little ebuild
> experience but I am a willing learner with a keen interest in
> Mono/dotNET technologies. I am not (yet) a Gentoo developer nor have
> I lots of experience with ebuilds however I have taken an inter
(Sorry that this mail does not contain the proper "References:";
I am not a regular reader of this list and therefore cannot "reply").
Ryan Hill wrote:
> USE flags should not affect CFLAGS unless there is a very good reason
A valid reason should be that upstream would prefer to add these flags.
On Thursday, July 01, 2010 08:53:19 Vaeth wrote:
> The debug USE flag in eix is also about convenience for the user:
> If eix segfaults, it prints instructions how to produce a backtrace
> in such a way which is most likely useful for upstream to locate
> the problem.
> Currently, these instruction
On Thu, 1 Jul 2010 14:53:19 +0200 (CEST)
Vaeth wrote:
> (Sorry that this mail does not contain the proper "References:";
> I am not a regular reader of this list and therefore cannot "reply").
>
> Ryan Hill wrote:
>
> > USE flags should not affect CFLAGS unless there is a very good reason
>
>
On 07/01/2010 11:00 PM, Ryan Hill wrote:
[...]
The way to control compiler flags in Gentoo is CFLAGS.
That is true. However, there's a problem; you can control package
options of individual packages with USE flags, but you can't control
compilation switches of individual packages with CFLAGS
On Thu, Jul 1, 2010 at 1:04 PM, Nikos Chantziaras wrote:
> On 07/01/2010 11:00 PM, Ryan Hill wrote:
>>
>> [...]
>> The way to control compiler flags in Gentoo is CFLAGS.
>
> That is true. However, there's a problem; you can control package options
> of individual packages with USE flags, but you
Ryan Hill wrote:
> Upstream is free to use whatever CFLAGS they see fit, as long as the
> user has the option of disabling them. This is simply done by appending
> the user's CFLAGS to those of the build system.
Since it is obvious that by _appending_ only the user's CFLAGS to your
own, you do n
Nikos Chantziaras wrote:
>
> If you use portage than you can control per-package CFLAGS using
> bashrc and /etc/portage/env or similar functionality.
This is correct, but the problem is that an ebuild author or
upstream cannot set a "default" here: IMHO, it shouldn't be
necessary for the user to
On Thu, Jul 1, 2010 at 3:14 PM, Vaeth wrote:
> Nikos Chantziaras wrote:
>>
>> If you use portage than you can control per-package CFLAGS using
>> bashrc and /etc/portage/env or similar functionality.
>
> This is correct, but the problem is that an ebuild author or
> upstream cannot set a "default
On Thu, 1 Jul 2010 23:44:17 +0200 (CEST)
Vaeth wrote:
> Ryan Hill wrote:
> > Upstream is free to use whatever CFLAGS they see fit, as long as the
> > user has the option of disabling them. This is simply done by appending
> > the user's CFLAGS to those of the build system.
>
> Since it is obvi
On Thu, 01 Jul 2010 23:04:10 +0300
Nikos Chantziaras wrote:
> On 07/01/2010 11:00 PM, Ryan Hill wrote:
> >[...]
> > The way to control compiler flags in Gentoo is CFLAGS.
>
> That is true. However, there's a problem; you can control package
> options of individual packages with USE flags, but
Ryan Hill posted on Thu, 01 Jul 2010 19:48:49 -0600 as excerpted:
> We've had per-package CFLAGS for quite a long time now. Maybe we need
> to advertise this a little more? There would certainly be a market for
> some util to manage all the per-package options that we have scattered
> around in
I've recently stumbled upon several packages unnecessarily using old
preserve_old_lib feature from eutils.eclass, namely:
libgnomekbd
libproxy
And then users hit issues like this:
https://bugs.gentoo.org/show_bug.cgi?id=326517#c5
Please only use the preserve_old_lib function in case of breaking
On 7/2/10 7:51 AM, Samuli Suominen wrote:
> It's a hack, not a solution
Should we make repoman issue a warning about it?
It already warns about using make -j1 as a workaround for upstream
issues. The new warning could be on the same level (yellow, not red).
Paweł
signature.asc
Description: Op
On 07/02/2010 08:51 AM, Samuli Suominen wrote:
> I've recently stumbled upon several packages unnecessarily using old
> preserve_old_lib feature from eutils.eclass, namely:
>
> libgnomekbd
> libproxy
>
> And then users hit issues like this:
>
> https://bugs.gentoo.org/show_bug.cgi?id=326517#c5
>
On 07/02/2010 08:54 AM, "Paweł Hajdan, Jr." wrote:
> On 7/2/10 7:51 AM, Samuli Suominen wrote:
>> It's a hack, not a solution
>
> Should we make repoman issue a warning about it?
>
> It already warns about using make -j1 as a workaround for upstream
> issues. The new warning could be on the same
On 07/02/2010 09:03 AM, Samuli Suominen wrote:
> On 07/02/2010 08:54 AM, "Paweł Hajdan, Jr." wrote:
>> On 7/2/10 7:51 AM, Samuli Suominen wrote:
>>> It's a hack, not a solution
>>
>> Should we make repoman issue a warning about it?
>>
>> It already warns about using make -j1 as a workaround for ups
17 matches
Mail list logo
