On Sat, Apr 7, 2018 at 12:57 PM, Lars Wendler wrote:
> On Sat, 7 Apr 2018 14:16:33 -0500 William Hubbs wrote:
>
>>On Sat, Apr 07, 2018 at 02:55:53PM -0400, Michael Orlitzky wrote:
>>> On 04/07/2018 02:44 PM, William Hubbs wrote:
>>> >
>>> > I'm with floppym on this one. Is there a specific reason
On Sat, 7 Apr 2018 14:16:33 -0500 William Hubbs wrote:
>On Sat, Apr 07, 2018 at 02:55:53PM -0400, Michael Orlitzky wrote:
>> On 04/07/2018 02:44 PM, William Hubbs wrote:
>> >
>> > I'm with floppym on this one. Is there a specific reason we enable
>> > them globally?
>>
>> It's a relic from b
On Sat, Apr 07, 2018 at 02:55:53PM -0400, Michael Orlitzky wrote:
> On 04/07/2018 02:44 PM, William Hubbs wrote:
> >
> > I'm with floppym on this one. Is there a specific reason we enable them
> > globally?
>
> It's a relic from before we had IUSE defaults.
>
>
> > Since there has been so littl
On 04/07/2018 02:44 PM, William Hubbs wrote:
>
> I'm with floppym on this one. Is there a specific reason we enable them
> globally?
It's a relic from before we had IUSE defaults.
> Since there has been so little discussion on this thread, I will start
> looking at what I need to do to remove t
On Thu, Jan 26, 2017 at 10:33:14PM -0500, Mike Gilbert wrote:
> I recently ran into a REQUIRED_USE constraint that required I select
> between berkdb and gdbm for an email client.
This has now hit stable and is affecting me because I can't upgrade the
email client without putting something in pac
On Fri, Jan 27, 2017 at 8:22 AM, Mike Gilbert wrote:
> On Fri, Jan 27, 2017 at 2:54 AM, Mart Raudsepp wrote:
>> Then there is no need to think about what is enabled globally or not.
>> Point being, use REQUIRED_USE sparingly, and rarely a good idea to
>> block things with common global USE flags,
Ühel kenal päeval, R, 27.01.2017 kell 11:22, kirjutas Mike Gilbert:
> On Fri, Jan 27, 2017 at 2:54 AM, Mart Raudsepp
> wrote:
> > Then there is no need to think about what is enabled globally or
> > not.
> > Point being, use REQUIRED_USE sparingly, and rarely a good idea to
> > block things with c
On 01/26/2017 10:33 PM, Mike Gilbert wrote:
>
> Is there any reason to have these USE flags enabled globally?
They are quite uncritical.
> These USE seem pretty package-specific in scope. On my system, they
> are used by around a dozen of 1000+ installed packages. I think it
> might make sense
On 01/27/2017 05:46 PM, William Hubbs wrote:
>> It breaks the highly sought after "Gentoo is about choice" mantra.
>> In this case, choice to not care and have the best chosen for me.
> Actually it doesn't. In this case the user should make a choice rather
> than the maintainer silently making a ch
On Fri, Jan 27, 2017 at 06:27:09PM +0200, Mart Raudsepp wrote:
> Ühel kenal päeval, R, 27.01.2017 kell 13:08, kirjutas Kristian
> Fiskerstrand:
> > On 01/27/2017 01:01 PM, Dirkjan Ochtman wrote:
> > > On Fri, Jan 27, 2017 at 8:54 AM, Mart Raudsepp
> > > wrote:
> > > > Ühel kenal päeval, N, 26.01.2
Ühel kenal päeval, R, 27.01.2017 kell 13:08, kirjutas Kristian
Fiskerstrand:
> On 01/27/2017 01:01 PM, Dirkjan Ochtman wrote:
> > On Fri, Jan 27, 2017 at 8:54 AM, Mart Raudsepp
> > wrote:
> > > Ühel kenal päeval, N, 26.01.2017 kell 22:33, kirjutas Mike
> > > Gilbert:
> > > > I recently ran into a
On Fri, Jan 27, 2017 at 2:54 AM, Mart Raudsepp wrote:
> Then there is no need to think about what is enabled globally or not.
> Point being, use REQUIRED_USE sparingly, and rarely a good idea to
> block things with common global USE flags, or demand a local USE flag
> based on a default enabled gl
On 27-01-2017 13:08:41 +0100, Kristian Fiskerstrand wrote:
> > On Fri, Jan 27, 2017 at 9:32 AM, Fabian Groffen wrote:
> >> Replying here because I think said email client is the one I recently
> >> added REQUIRED_USE constraints for.
> >>
> >> Reason I added it is because it greatly simplified the
On 01/27/2017 01:01 PM, Dirkjan Ochtman wrote:
> On Fri, Jan 27, 2017 at 8:54 AM, Mart Raudsepp wrote:
>> Ühel kenal päeval, N, 26.01.2017 kell 22:33, kirjutas Mike Gilbert:
>>> I recently ran into a REQUIRED_USE constraint that required I select
>>> between berkdb and gdbm for an email client.
>>
On Fri, Jan 27, 2017 at 4:33 AM, Mike Gilbert wrote:
> Looking through our profiles, I see we have both berkdb and gdbm
> enabled "globally".
>
> default/linux/make.defaults:USE="berkdb crypt ipv6 ncurses nls pam
> readline ssl tcpd zlib"
> releases/make.defaults:USE="acl gdbm nptl unicode"
>
> Is
Ühel kenal päeval, R, 27.01.2017 kell 13:16, kirjutas Mart Raudsepp:
> If anything, I think this is a suggestion that *maybe* we should a
> > way to
> > specify a mechanism for allowing a default to be chosen from a
> > mutually
> > exclusive set, and then:
>
> Sure, I have some thoughts for this
Ühel kenal päeval, R, 27.01.2017 kell 23:58, kirjutas Kent Fredric:
> On Fri, 27 Jan 2017 09:32:23 +0100
> Fabian Groffen wrote:
>
> > I'm interested to hear how other people feel about this.
>
> Yeah. Pretty much my reaction to
>
> Mart Raudsepp wrote:
>
> > The maintainer should be giving
On Fri, 27 Jan 2017 09:32:23 +0100
Fabian Groffen wrote:
> I'm interested to hear how other people feel about this.
Yeah. Pretty much my reaction to
Mart Raudsepp wrote:
> The maintainer should be giving the choice of both,
> but if only one can be chosen, the maintainer should make the choi
Replying here because I think said email client is the one I recently
added REQUIRED_USE constraints for.
Reason I added it is because it greatly simplified the ebuild: it's not
just bdb and gdbm, but also tokyocabinet, qdbm and lmdb, with as result
a lot of if-else-casing which implemented the im
Ühel kenal päeval, N, 26.01.2017 kell 22:33, kirjutas Mike Gilbert:
> I recently ran into a REQUIRED_USE constraint that required I select
> between berkdb and gdbm for an email client.
There shouldn't be a REQUIRED_USE constraint that forces you to select
one or the other. The maintainer should b
I recently ran into a REQUIRED_USE constraint that required I select
between berkdb and gdbm for an email client.
Looking through our profiles, I see we have both berkdb and gdbm
enabled "globally".
default/linux/make.defaults:USE="berkdb crypt ipv6 ncurses nls pam
readline ssl tcpd zlib"
release
21 matches
Mail list logo
