1 |
Replying here because I think said email client is the one I recently |
2 |
added REQUIRED_USE constraints for. |
3 |
|
4 |
Reason I added it is because it greatly simplified the ebuild: it's not |
5 |
just bdb and gdbm, but also tokyocabinet, qdbm and lmdb, with as result |
6 |
a lot of if-else-casing which implemented the implicit defaults before. |
7 |
I didn't realise changing this to REQUIRED_USE resulted in a conflict on |
8 |
default profiles, because I (obviously) have a package.use entry for the |
9 |
package. |
10 |
|
11 |
You mention REQUIRED_USE should be used sparingly, I think I see your |
12 |
reasoning, but if so, then why did we add it in the first place? Since |
13 |
the ebuild will only use one of the db backends, when multiple are |
14 |
selected, the package manager will falsely think both are in use (and |
15 |
trigger rebuilds, etc.). Isn't the point to express the actual |
16 |
situation as correctly as possible for the PM to do a better job? |
17 |
I also like the ebuild being way less convoluted, but I can overcome |
18 |
that is necessary. |
19 |
|
20 |
I'm interested to hear how other people feel about this. |
21 |
|
22 |
Thanks, |
23 |
Fabian |
24 |
|
25 |
|
26 |
On 27-01-2017 09:54:00 +0200, Mart Raudsepp wrote: |
27 |
> Ühel kenal päeval, N, 26.01.2017 kell 22:33, kirjutas Mike Gilbert: |
28 |
> > I recently ran into a REQUIRED_USE constraint that required I select |
29 |
> > between berkdb and gdbm for an email client. |
30 |
> |
31 |
> There shouldn't be a REQUIRED_USE constraint that forces you to select |
32 |
> one or the other. The maintainer should be giving the choice of both, |
33 |
> but if only one can be chosen, the maintainer should make the choice |
34 |
> for you by preferring one of them. Likely gdbm, given berkdb licensing |
35 |
> saga. |
36 |
> Though I guess this is a little bit more problematic when that DB is |
37 |
> long living, but I think it should still work good enough with this |
38 |
> guideline. |
39 |
> |
40 |
> Then there is no need to think about what is enabled globally or not. |
41 |
> Point being, use REQUIRED_USE sparingly, and rarely a good idea to |
42 |
> block things with common global USE flags, or demand a local USE flag |
43 |
> based on a default enabled global USE flag without locally USE |
44 |
> defaulting that global flag too - and other such cases. |
45 |
> |
46 |
> I'd talk to the maintainer(s) of such package(s) via bugzilla or other |
47 |
> means and discuss such REQUIRED_USE potential overuse. |
48 |
> |
49 |
> > Looking through our profiles, I see we have both berkdb and gdbm |
50 |
> > enabled "globally". |
51 |
> > |
52 |
> > default/linux/make.defaults:USE="berkdb crypt ipv6 ncurses nls pam |
53 |
> > readline ssl tcpd zlib" |
54 |
> > releases/make.defaults:USE="acl gdbm nptl unicode" |
55 |
> > |
56 |
> > Is there any reason to have these USE flags enabled globally? |
57 |
> > |
58 |
> > These USE seem pretty package-specific in scope. On my system, they |
59 |
> > are used by around a dozen of 1000+ installed packages. I think it |
60 |
> > might make sense to migrate them to appropriate IUSE defaults, or |
61 |
> > leave them disabled where they do not provide critical functionality. |
62 |
> |
63 |
> |
64 |
|
65 |
-- |
66 |
Fabian Groffen |
67 |
Gentoo on a different level |