1 |
On Fri, Jan 27, 2017 at 4:33 AM, Mike Gilbert <floppym@g.o> wrote: |
2 |
> Looking through our profiles, I see we have both berkdb and gdbm |
3 |
> enabled "globally". |
4 |
> |
5 |
> default/linux/make.defaults:USE="berkdb crypt ipv6 ncurses nls pam |
6 |
> readline ssl tcpd zlib" |
7 |
> releases/make.defaults:USE="acl gdbm nptl unicode" |
8 |
> |
9 |
> Is there any reason to have these USE flags enabled globally? |
10 |
|
11 |
Good question... I already disable them, I think, as it doesn't really |
12 |
make sense from my perspective to enable them globally. I think |
13 |
letting packages set their own defaults with IUSE would probably be a |
14 |
better solution. |
15 |
|
16 |
On Fri, Jan 27, 2017 at 8:54 AM, Mart Raudsepp <leio@g.o> wrote: |
17 |
> Ühel kenal päeval, N, 26.01.2017 kell 22:33, kirjutas Mike Gilbert: |
18 |
>> I recently ran into a REQUIRED_USE constraint that required I select |
19 |
>> between berkdb and gdbm for an email client. |
20 |
> |
21 |
> There shouldn't be a REQUIRED_USE constraint that forces you to select |
22 |
> one or the other. The maintainer should be giving the choice of both, |
23 |
> but if only one can be chosen, the maintainer should make the choice |
24 |
> for you by preferring one of them. Likely gdbm, given berkdb licensing |
25 |
> saga. |
26 |
|
27 |
I'm not sure this makes sense to me. If the package will actually |
28 |
select one implementation out of a set, it makes sense to me that the |
29 |
maintainer for that package makes that choice explicit towards the |
30 |
user. In that case, setting REQUIRED_USE accordingly seems exactly |
31 |
right. The maintainer should set a good default, but if the user's USE |
32 |
settings are inconclusive in getting to the choice of implementation, |
33 |
it's better to whine explicitly than try to guess implicitly what the |
34 |
user wanted. |
35 |
|
36 |
On Fri, Jan 27, 2017 at 9:32 AM, Fabian Groffen <grobian@g.o> wrote: |
37 |
> Replying here because I think said email client is the one I recently |
38 |
> added REQUIRED_USE constraints for. |
39 |
> |
40 |
> Reason I added it is because it greatly simplified the ebuild: it's not |
41 |
> just bdb and gdbm, but also tokyocabinet, qdbm and lmdb, with as result |
42 |
> a lot of if-else-casing which implemented the implicit defaults before. |
43 |
> I didn't realise changing this to REQUIRED_USE resulted in a conflict on |
44 |
> default profiles, because I (obviously) have a package.use entry for the |
45 |
> package. |
46 |
|
47 |
I don't see Mike saying you got it wrong here. Reading your email, I |
48 |
think you did the right thing. |
49 |
|
50 |
Cheers, |
51 |
|
52 |
Dirkjan |