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