1 |
Dnia 2015-09-10, o godz. 08:46:41 |
2 |
Alec Ten Harmsel <alec@××××××××××××××.com> napisał(a): |
3 |
|
4 |
> If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild? |
5 |
> From the "I want a usable system with as little code as possible" and "I |
6 |
> want a system tailored to my needs" standpoints, having only one version |
7 |
> of gtk makes quite a bit of sense. |
8 |
|
9 |
This is the same case as with many other libraries which suffered major |
10 |
API changes -- SDL, for example. Just because upstream *thinks* they |
11 |
support two GTK+ versions, doesn't mean they do. Only one of the |
12 |
versions is well-tested, and the second one sometimes isn't tested at |
13 |
all, neither by upstream nor by the developer. |
14 |
|
15 |
The happy end result is, sometimes user has choice between 'working |
16 |
package' and 'package randomly segfaulting when you least expect it'. |
17 |
Of course, it's all hidden nicely under USE=gtk2 and USE=gtk3, so just |
18 |
*maybe* if you have the time to read local flag descriptions for every |
19 |
single package you may notice which of the flags should be enabled to |
20 |
get a working app. |
21 |
|
22 |
But yes, wasting people's time and offering easy way to data loss is |
23 |
better than not supporting some imaginary corner case when you can |
24 |
actually use some fancy combination of applications that can actually |
25 |
run without that one library without losing stability and benefit you. |
26 |
|
27 |
I hope you are ready to pay the developers who will waste their time |
28 |
figuring out what goes wrong when you report a bug, until they figure |
29 |
out it's because you have forced GTK+ version which upstream thought |
30 |
they're supporting but they do not. That's certainly a better |
31 |
alternative than paying for hardware that can handle loading two |
32 |
libraries. |
33 |
|
34 |
-- |
35 |
Best regards, |
36 |
Michał Górny |
37 |
<http://dev.gentoo.org/~mgorny/> |