1 |
On Sat, Jun 23, 2012 at 9:45 AM, Gilles Dartiguelongue <eva@g.o> wrote: |
2 |
> Le samedi 23 juin 2012 à 14:40 +0100, Ciaran McCreesh a écrit : |
3 |
>> |
4 |
>> I'd like to know why using USE flags until a nicer solution is |
5 |
>> available |
6 |
>> is sufficiently terrible that it warrants a hackaround. |
7 |
> |
8 |
> remember qt3/qt4, gtk/gtk2. We want to avoid repeating these "mistakes" |
9 |
> hence the guidelines already exposed back when we introduced gtk3 to the |
10 |
> tree. |
11 |
> |
12 |
> As you may have noticed, this is still the solution applied for things |
13 |
> hard to split or slot like gtk-vnc or avahi but we didn't see the need |
14 |
> to have such USE flags when the library was so easily slottable. |
15 |
> |
16 |
|
17 |
It's funny you bring up qt3/qt4 and gtk/gtk2 since I'm only of the few |
18 |
developers that worked on resolving both of those as they came and |
19 |
went. Right now the resources we've got available to us from a Package |
20 |
Manager stand point. Being a Gentoo dev for so long has allowed me to |
21 |
see how our distro has evolved so let me give you a short walk down |
22 |
memory lane, when gtk/gtk2 & qt3/qt4 occurred we had the following: |
23 |
- Portage 1.x (gtk/gtk2) / Portage 2.0.x (qt3/qt4) |
24 |
- No EAPI |
25 |
- No way to add features quickly to the Package Manager and the spec for it. |
26 |
|
27 |
During gtk/gtk2, the rule was you had to wait until a feature was |
28 |
available in the STABLE version of Portage, 4 releases back before you |
29 |
could use a new feature. For everyone's knowledge, we did 4 releases a |
30 |
year then. We knew our solution to gtk/gtk2 sucked and we hated it but |
31 |
there was absolutely nothing we could do about it. It was a bitter |
32 |
battle of band aids and hacks that we couldn't wait to get rid of. We |
33 |
even attempted to throw gtk1 out of the tree entirely (ah the XMMS |
34 |
flamewar) to get rid of the hacks. You couldn't even modify eclasses |
35 |
since they weren't stored with the install, which lead to the -rX |
36 |
revisioning of eclasses. On top of all this, Portage 1.x SUCKED to |
37 |
modify or hack at. The only solution with that codebase was to nuke it |
38 |
from orbit, which we finally did with Portage 2.0.x. |
39 |
|
40 |
During qt3/qt4, the rule was you had to wait until the feature you |
41 |
were trying to use was in a STABLE Portage for 6 months. We didn't |
42 |
have a lot of options available but we worked with the current Portage |
43 |
maintainer at the time to get some of the resolver improved and fixed |
44 |
and get those updates pushed out to the tree as quickly as possible. |
45 |
Once the updates were available the hacks went away and life was |
46 |
better. |
47 |
|
48 |
Now fast forward to 2011/2012, we were obviously aware that the |
49 |
gtk2/gtk3 change would cause some problems. Heck people encountered it |
50 |
when they tried to add ebuilds to the tree. The right path forward was |
51 |
to speak to Zac, Brian and the rest of the PMS guys and see what the |
52 |
best solution was. If it was implementing some new features then we |
53 |
could have done that and gotten and EAPI approved quickly and had it |
54 |
available before we even saw the first gtk3 ebuild unmasked. But alas, |
55 |
that wasn't the case and here we are today. So here's what I suggest, |
56 |
let's stop bickering and revisit the "hacks" you did to make things |
57 |
work. Speak to Zac, Brian and the rest of the PMS guys and get what |
58 |
you need implemented as a feature and get that feature into the very |
59 |
next EAPI bump. Fix the tree to use that EAPI and get rid of the |
60 |
hacks. You'll thank yourselves in the long run since things will be |
61 |
easier to maintain and you can focus on what you enjoy doing. |
62 |
|
63 |
-- |
64 |
Doug Goldstein |