Re: [gentoo-dev] gtk3 useflag and support of older toolkits

[Doug Goldstein]

On Sat, Jun 23, 2012 at 9:45 AM, Gilles Dartiguelongue <eva@g.o> 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