1 |
On 02/06/16 09:48 PM, Nick Vinson wrote: |
2 |
> On 06/02/2016 08:08 AM, Raymond Jennings wrote: |
3 |
>> use case: Telling a package to build a gui without deciding which one |
4 |
>> to build. Also helps in cases where you have package A that can only |
5 |
>> build a qt gui, and package B that can build both qt and gtk, and |
6 |
>> package C that can build gtk only. You want to have a gui for all |
7 |
>> three, but you don't want to hav epackage B build both guis and at the |
8 |
>> same time while you may prefer qt, you don't want to leave package C |
9 |
>> without a gui. |
10 |
> |
11 |
> How do you decide which one package B builds in such a case? |
12 |
> |
13 |
> Honestly, I don't think this is a good idea. The rationale and |
14 |
> suggested implementation just don't bring enough benefit in my opinion. |
15 |
> Often times it's hard enough to research a reported issue with the |
16 |
> current implementation. Having a flag like 'gui' whose behavior |
17 |
> (potentially) changes based on what profile is being used makes things |
18 |
> considerably harder. It would no longer be a simple matter of matching |
19 |
> versions and USE flags, the package maintainer would also need to setup |
20 |
> an equivalent system with the same profile or research what the 'gui' |
21 |
> flag with profile 'x' does and setup an equivalent USE flag set. |
22 |
|
23 |
|
24 |
OK this makes absolutely no sense. |
25 |
|
26 |
USE=gui is about building the graphical user interface that an |
27 |
application offers, when it is optional. That's it. What |
28 |
dependencies that means and so on have nothing to do with the flag. |
29 |
It's the same as USE="server" to build the server daemon for an app |
30 |
that provides both client and server. |
31 |
|
32 |
You get that use flags are not supposed to represent dependencies |
33 |
right, but features of the package?? If you're only able to debug a |
34 |
build of your package because the flag is called gtk instead of gui, |
35 |
well... |
36 |
|
37 |
|
38 |
> |
39 |
> Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly |
40 |
> do the same thing. The only thing they don't do (as I understand the |
41 |
> profiles) is enable GUI support for packages that don't support the |
42 |
> preferred libraries. Is that really enough justification to implement |
43 |
> this flag? |
44 |
|
45 |
Yes. |
46 |
|
47 |
More specifically, the cleanup of all of those other uses of flags |
48 |
that are there just to trigger a gui build instead of to indicate a |
49 |
choice between options, is also enough justification. Think about a |
50 |
wayland system -- there's lots of packages that IUSE="X" to build |
51 |
their gui implementation. If someone wanting wayland set USE="-X" |
52 |
then they don't get the gui app even if it'll work in wayland just fine. |
53 |
|
54 |
Yes, the USE=gui on this hypothetical app may well pull in Xorg libs, |
55 |
but that's not a reason to keep the flag called "X", because again, |
56 |
its about the feature of the package *not* the dependency. |
57 |
|
58 |
|
59 |
> |
60 |
> As a maintainer I'd ask that, at the very least, a more compelling |
61 |
> reason than "it's too annoying to update package.use" is given. I find |
62 |
> the argument against putting all the flags in global a valid but weak as |
63 |
> there are already mitigations for that scenario. Perhaps I'm missing |
64 |
> something, but I'm not convinced this will provide a significant enough |
65 |
> benefit to the average Gentoo user to offset the increased |
66 |
> troubleshooting demand it'll put on Gentoo's developers, maintainers, |
67 |
> and proxy-maintainers. |
68 |
|
69 |
|
70 |
Again, you will very much need to elaborate on what these increased |
71 |
troubleshooting demands are. If anything, I see this flag, which will |
72 |
allow the various tooklit flags to just mean a choice between |
73 |
toolkits, to make things *easier* for troubleshooting, not harder. |