Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Matt Turner]

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 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 these use flags from
>>> > the profiles.
>>>
>>> There's probably a few packages that will need IUSE defaults to avoid
>>> breakage, and everyone else should get fair warning before the flags
>>> are turned off by default.
>>
>>There is the case of packages that optionally use a db back end,
>>and I would argue that those may not need iuse defaults.
>>
>>It could also be argued that having one backend enabled globally is
>>good for consistency, but that would end up leading down a bikeshed
>>path that I'm not sure we should go down. I'm just not sure it makes
>>sense to enable more than one of these backends globally.
>>
>>Thoughts?
>>
>>William
>>
>
> Considering the questionable license situation with latest sys-libs/db
> releases (AGPL), I'd say we should prefer gdbm over berkdb in case we
> want to keep one db backend default enabled.
> IIRC Fedora is even trying to entirely getting rid of berkdb.

Interesting. I wasn't aware of that. Here's a link with more information:

https://bugzilla.redhat.com/show_bug.cgi?id=1361971

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Lars Wendler]

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 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 these use flags from
>> > the profiles.  
>> 
>> There's probably a few packages that will need IUSE defaults to avoid
>> breakage, and everyone else should get fair warning before the flags
>> are turned off by default.  
>
>There is the case of packages that optionally use a db back end,
>and I would argue that those may not need iuse defaults.
>
>It could also be argued that having one backend enabled globally is
>good for consistency, but that would end up leading down a bikeshed
>path that I'm not sure we should go down. I'm just not sure it makes
>sense to enable more than one of these backends globally.
>
>Thoughts?
>
>William
>

Considering the questionable license situation with latest sys-libs/db
releases (AGPL), I'd say we should prefer gdbm over berkdb in case we
want to keep one db backend default enabled.
IIRC Fedora is even trying to entirely getting rid of berkdb.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpZtUTHcE5fW.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[William Hubbs]

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 little discussion on this thread, I will start
> > looking at what I need to do to remove these use flags from the
> > profiles.
> 
> There's probably a few packages that will need IUSE defaults to avoid
> breakage, and everyone else should get fair warning before the flags are
> turned off by default.

There is the case of packages that optionally use a db back end,
and I would argue that those may not need iuse defaults.

It could also be argued that having one backend enabled globally is good
for consistency, but that would end up leading down a bikeshed path that
I'm not sure we should go down. I'm just not sure it makes sense to
enable more than one of these backends globally.

Thoughts?

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Michael Orlitzky]

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 these use flags from the
> profiles.

There's probably a few packages that will need IUSE defaults to avoid
breakage, and everyone else should get fair warning before the flags are
turned off by default.

But this is a noble goal; thanks.

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[William Hubbs]

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 package.use.

> 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 there any reason to have these USE flags enabled globally?
> 
> 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 to migrate them to appropriate IUSE defaults, or
> leave them disabled where they do not provide critical functionality.

I'm with floppym on this one. Is there a specific reason we enable them
globally?

Since there has been so little discussion on this thread, I will start
looking at what I need to do to remove these use flags from the
profiles.

Thanks,

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Matt Turner]

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, or demand a local USE flag
>> based on a default enabled global USE flag without locally USE
>> defaulting that global flag too - and other such cases.
>
> I didn't really mean for this to turn into a thread about the merits
> of REQUIRED_USE; in hindsight I should have left out that first
> sentence.
>
> Regardless of the REQUIRED_USE discussion, I don't think it makes
> sense to have berkdb and gdbm in USE in make.defaults. I would like to
> move them to IUSE defaults or package.use if necessary.

I think you should feel free to proceed with such a change.

FWIW, disabling these USE flags (and fortran) are among the first
changes I made to a new make.conf.

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Mart Raudsepp]

Ü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 common global USE flags, or demand a local USE
> > flag
> > based on a default enabled global USE flag without locally USE
> > defaulting that global flag too - and other such cases.
> 
> I didn't really mean for this to turn into a thread about the merits
> of REQUIRED_USE; in hindsight I should have left out that first
> sentence.
> 
> Regardless of the REQUIRED_USE discussion, I don't think it makes
> sense to have berkdb and gdbm in USE in make.defaults. I would like
> to
> move them to IUSE defaults or package.use if necessary.

That sounds great to me when done with proper care as an interim
solution.
If they aren't both global enabled, the concerns about REQUIRED_USE
here are lessened.


Mart

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Michael Orlitzky]

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 to migrate them to appropriate IUSE defaults, or
> leave them disabled where they do not provide critical functionality.
> 

+1

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Kristian Fiskerstrand]

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 choice behind their back.

There is an argument to be made for sane defaults in profiles as well as
default IUSE specification in this though to provide a better user
experience, but the underlying mechanism should be explicit.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[William Hubbs]

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.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 be giving the choice of
> > > > both,
> > > > but if only one can be chosen, the maintainer should make the
> > > > choice
> > > > for you by preferring one of them. Likely gdbm, given berkdb
> > > > licensing
> > > > saga.
> > > 
> > > I'm not sure this makes sense to me. If the package will actually
> > > select one implementation out of a set, it makes sense to me that
> > > the
> > > maintainer for that package makes that choice explicit towards the
> > > user. In that case, setting REQUIRED_USE accordingly seems exactly
> > > right. The maintainer should set a good default, but if the user's
> > > USE
> > > settings are inconclusive in getting to the choice of
> > > implementation,
> > > it's better to whine explicitly than try to guess implicitly what
> > > the
> > > user wanted.
> > 
> > I tend to agree with this sentiment, explicit over implicit behavior
> > ensures better debugging ability and security considerations.

I agree, I prefer explicit strongly over implicit.

> 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 choice behind their back.

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Mart Raudsepp]

Ü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 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 be giving the choice of
> > > both,
> > > but if only one can be chosen, the maintainer should make the
> > > choice
> > > for you by preferring one of them. Likely gdbm, given berkdb
> > > licensing
> > > saga.
> > 
> > I'm not sure this makes sense to me. If the package will actually
> > select one implementation out of a set, it makes sense to me that
> > the
> > maintainer for that package makes that choice explicit towards the
> > user. In that case, setting REQUIRED_USE accordingly seems exactly
> > right. The maintainer should set a good default, but if the user's
> > USE
> > settings are inconclusive in getting to the choice of
> > implementation,
> > it's better to whine explicitly than try to guess implicitly what
> > the
> > user wanted.
> 
> I tend to agree with this sentiment, explicit over implicit behavior
> ensures better debugging ability and security considerations.
> 

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.

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[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 common global USE flags, or demand a local USE flag
> based on a default enabled global USE flag without locally USE
> defaulting that global flag too - and other such cases.

I didn't really mean for this to turn into a thread about the merits
of REQUIRED_USE; in hindsight I should have left out that first
sentence.

Regardless of the REQUIRED_USE discussion, I don't think it makes
sense to have berkdb and gdbm in USE in make.defaults. I would like to
move them to IUSE defaults or package.use if necessary.

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Fabian Groffen]

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 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 implicit defaults before.
> >> I didn't realise changing this to REQUIRED_USE resulted in a conflict on
> >> default profiles, because I (obviously) have a package.use entry for the
> >> package.
> > I don't see Mike saying you got it wrong here. Reading your email, I
> > think you did the right thing.
> 
> Yup

That blurb was more directed at Mart ;)  I think I just explained why I
did what I did.  The scenario in older ebuilds (without REQUIRED_USE)
was basically the scenario that Mart suggested to be perferable over the
new REQUIRED_USE scenario.

I'm not looking for wrong/right.  I'm looking for concensus on this
topic, then I will likely change the ebuild to match concensus.

Fabian


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[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 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 be giving the choice of both,
>> but if only one can be chosen, the maintainer should make the choice
>> for you by preferring one of them. Likely gdbm, given berkdb licensing
>> saga.
> I'm not sure this makes sense to me. If the package will actually
> select one implementation out of a set, it makes sense to me that the
> maintainer for that package makes that choice explicit towards the
> user. In that case, setting REQUIRED_USE accordingly seems exactly
> right. The maintainer should set a good default, but if the user's USE
> settings are inconclusive in getting to the choice of implementation,
> it's better to whine explicitly than try to guess implicitly what the
> user wanted.

I tend to agree with this sentiment, explicit over implicit behavior
ensures better debugging ability and security considerations.

> 
> 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 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 implicit defaults before.
>> I didn't realise changing this to REQUIRED_USE resulted in a conflict on
>> default profiles, because I (obviously) have a package.use entry for the
>> package.
> I don't see Mike saying you got it wrong here. Reading your email, I
> think you did the right thing.

Yup

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Dirkjan Ochtman]

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 there any reason to have these USE flags enabled globally?

Good question... I already disable them, I think, as it doesn't really
make sense from my perspective to enable them globally. I think
letting packages set their own defaults with IUSE would probably be a
better solution.

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.
>
> There shouldn't be a REQUIRED_USE constraint that forces you to select
> one or the other. The maintainer should be giving the choice of both,
> but if only one can be chosen, the maintainer should make the choice
> for you by preferring one of them. Likely gdbm, given berkdb licensing
> saga.

I'm not sure this makes sense to me. If the package will actually
select one implementation out of a set, it makes sense to me that the
maintainer for that package makes that choice explicit towards the
user. In that case, setting REQUIRED_USE accordingly seems exactly
right. The maintainer should set a good default, but if the user's USE
settings are inconclusive in getting to the choice of implementation,
it's better to whine explicitly than try to guess implicitly what the
user wanted.

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 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 implicit defaults before.
> I didn't realise changing this to REQUIRED_USE resulted in a conflict on
> default profiles, because I (obviously) have a package.use entry for the
> package.

I don't see Mike saying you got it wrong here. Reading your email, I
think you did the right thing.

Cheers,

Dirkjan

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Mart Raudsepp]

Ü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 and a rough draft, at least in my
> head :)
> I don't have it as a priority to sketch it out well alone, but if
> someone is honestly interested, I could braindump my ideas in
> realtime
> medium. Or someone thinks of them themselves :)

I wrote a bit about it in my USE_EXPAND=gui proposal.
https://archives.gentoo.org/gentoo-dev/message/cc39dfafcb33ac0d345c26c0
475723b8

That's the copy of my piratepad draft on the subject. In the end
there's a section on it under future ideas.

The initial thread start was
https://archives.gentoo.org/gentoo-dev/message/a2de58fcbf9f214362cd5fdb5f67e6b2
These were the only 2 e-mails in that thread, everyone was busy
bikeshedding my USE=gui proposal at
https://archives.gentoo.org/gentoo-dev/message/eecad370248118c474a0d819fa7f3576
with some of the multi-choice aspects coming up there.

Any future complaints by QA or otherwise about versioned gtk USE flags
and whatnot get pointed to these, to pick up and actually go forward
with this, not just complain. Anyhow, that's off-topic for the
REQUIRED_USE stuff here.


Mart

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Mart Raudsepp]

Ü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 the choice of both,
> > but if only one can be chosen, the maintainer should make the
> > choice
> > for you by preferring one of them. Likely gdbm, given berkdb
> > licensing
> > saga.
> 
> Brought the same question to me:
> 
> If the design is intended to force your hand when you have both, what
> is indeed
> the point of a REQUIRED_USE feature at all?

It can be very useful in some cases, especially when these cases
involve local USE flags in a way that the errors come after enabling
something locally in an unsuitable way.
But yes, ideally the package manager would have a clue about what
happened for the cases like the one in question, but REQUIRED_USE
provided a faster solution to some of the problems that could be
implemented in package managers in a reasonable time for the EAPI this
was introduced in.
We could work on top of this in a future EAPI.

> If "choose a useflag for the user" is something that is happening, it
> should
> at least be *visible* to the user that this is happening, not being a
> silent
> decision that didn't allow the user to have any say in the matter.
> 
> What if the feature you chose instead, was contrary to the one they
> wanted?
> 
> 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 and a rough draft, at least in my
head :)
I don't have it as a priority to sketch it out well alone, but if
someone is honestly interested, I could braindump my ideas in realtime
medium. Or someone thinks of them themselves :)

> a. Inform the user via pretend output that this automatic conflict
> reduction
>    has been performed
> 
> b. Define a portage option that disables automatic conflict
> resolution for
>    required USE, so users who hate (a) can turn it off.
> 
> 
> But as it stands, Mart's suggestion of "Hey, just don't use required
> use,
> decide for the user" stands essentially as a regression against
> portage itself.

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[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 the choice of both,
> but if only one can be chosen, the maintainer should make the choice
> for you by preferring one of them. Likely gdbm, given berkdb licensing
> saga.

Brought the same question to me:

If the design is intended to force your hand when you have both, what is indeed
the point of a REQUIRED_USE feature at all?

If "choose a useflag for the user" is something that is happening, it should
at least be *visible* to the user that this is happening, not being a silent
decision that didn't allow the user to have any say in the matter.

What if the feature you chose instead, was contrary to the one they wanted?

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:

a. Inform the user via pretend output that this automatic conflict reduction
   has been performed

b. Define a portage option that disables automatic conflict resolution for
   required USE, so users who hate (a) can turn it off.


But as it stands, Mart's suggestion of "Hey, just don't use required use,
decide for the user" stands essentially as a regression against portage itself.


pgpmoqwpQFHxO.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Fabian Groffen]

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 implicit defaults before.
I didn't realise changing this to REQUIRED_USE resulted in a conflict on
default profiles, because I (obviously) have a package.use entry for the
package.

You mention REQUIRED_USE should be used sparingly, I think I see your
reasoning, but if so, then why did we add it in the first place?  Since
the ebuild will only use one of the db backends, when multiple are
selected, the package manager will falsely think both are in use (and
trigger rebuilds, etc.).  Isn't the point to express the actual
situation as correctly as possible for the PM to do a better job?
I also like the ebuild being way less convoluted, but I can overcome
that is necessary.

I'm interested to hear how other people feel about this.

Thanks,
Fabian


On 27-01-2017 09:54:00 +0200, 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.
> 
> There shouldn't be a REQUIRED_USE constraint that forces you to select
> one or the other. The maintainer should be giving the choice of both,
> but if only one can be chosen, the maintainer should make the choice
> for you by preferring one of them. Likely gdbm, given berkdb licensing
> saga.
> Though I guess this is a little bit more problematic when that DB is
> long living, but I think it should still work good enough with this
> guideline.
> 
> 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 global USE flag without locally USE
> defaulting that global flag too - and other such cases.
> 
> I'd talk to the maintainer(s) of such package(s) via bugzilla or other
> means and discuss such REQUIRED_USE potential overuse.
> 
> > 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 there any reason to have these USE flags enabled globally?
> > 
> > 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 to migrate them to appropriate IUSE defaults, or
> > leave them disabled where they do not provide critical functionality.
> 
> 

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Mart Raudsepp]

Ü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 be giving the choice of both,
but if only one can be chosen, the maintainer should make the choice
for you by preferring one of them. Likely gdbm, given berkdb licensing
saga.
Though I guess this is a little bit more problematic when that DB is
long living, but I think it should still work good enough with this
guideline.

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 global USE flag without locally USE
defaulting that global flag too - and other such cases.

I'd talk to the maintainer(s) of such package(s) via bugzilla or other
means and discuss such REQUIRED_USE potential overuse.

> 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 there any reason to have these USE flags enabled globally?
> 
> 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 to migrate them to appropriate IUSE defaults, or
> leave them disabled where they do not provide critical functionality.

[gentoo-dev] berkdb and gdbm in global USE defaults

[Mike Gilbert]

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"
releases/make.defaults:USE="acl gdbm nptl unicode"

Is there any reason to have these USE flags enabled globally?

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 to migrate them to appropriate IUSE defaults, or
leave them disabled where they do not provide critical functionality.