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

June 09th, 2012 - 10:50 pm ET by hasufell | Report spam
Bug #420433 lately introduced the discussion again if and when we should
support older (deprecated) toolkit versions.

As for the named bug it may make sense to support it, cause the gtk3
useflag would lead to different (reduced) functionality of that package.
(but that shall not be the discussion here)

Generally I think gtk3 useflags should be avoided and only be a
workaround during migration to gtk+:3. Optimally gtk+:3 should always be
forced when available and not leading to major issues.
On the other hand... if gtk+:3 implementation is broken I would suggest
to simply force gtk+:2 without any gtk3 useflag. So we have ONE working
toolkit version.

Introducing stuff like gtk3 useflag will let users think this is about
choice, but it's actually not (gtk+:2 is not being developed any longer
afais).

Would it make sense to add a tracker for packages currently using gtk3
useflag, so this will not become a habit and only be a workaround?


# quse -N gtk3
app-editors/emacs/emacs-24.1_rc.ebuild
app-editors/emacs-vcs/emacs-vcs-24.1.9999-r1.ebuild
app-emulation/virt-viewer/virt-viewer-0.4.2.ebuild
app-emulation/virt-viewer/virt-viewer-0.5.2.ebuild
app-emulation/virt-viewer/virt-viewer-0.5.3.ebuild
app-i18n/fcitx/fcitx-4.2.1.ebuild
app-i18n/fcitx/fcitx-4.2.4.ebuild
app-i18n/fcitx-configtool/fcitx-configtool-0.4.1.ebuild
app-i18n/fcitx-configtool/fcitx-configtool-0.4.4.ebuild
app-i18n/ibus/ibus-1.4.1.ebuild
app-i18n/ibus-unikey/ibus-unikey-0.6.1.ebuild
app-i18n/uim/uim-1.7.1-r1.ebuild
app-i18n/uim/uim-1.7.1.ebuild
app-i18n/uim/uim-1.7.3.ebuild
app-i18n/uim/uim-1.8.0.ebuild
app-office/libreoffice/libreoffice-3.6.9999.ebuild
app-office/libreoffice/libreoffice-9999-r2.ebuild
gnome-base/librsvg/librsvg-2.34.1-r1.ebuild
gnome-base/librsvg/librsvg-2.34.2.ebuild
lxde-base/lxdm/lxdm-0.4.1-r1.ebuild
lxde-base/lxdm/lxdm-0.4.1-r2.ebuild
lxde-base/lxdm/lxdm-0.4.1-r4.ebuild
lxde-base/lxdm/lxdm-0.4.1-r5.ebuild
media-libs/libcanberra/libcanberra-0.28-r5.ebuild
media-plugins/audacious-plugins/audacious-plugins-3.2.2-r1.ebuild
media-plugins/audacious-plugins/audacious-plugins-3.2.3.ebuild
media-sound/audacious/audacious-3.2.2-r1.ebuild
media-sound/audacious/audacious-3.2.3.ebuild
media-sound/mp3splt-gtk/mp3splt-gtk-0.7.0.930.ebuild
media-sound/mp3splt-gtk/mp3splt-gtk-0.7.1.ebuild
media-sound/mp3splt-gtk/mp3splt-gtk-0.7.2.ebuild
net-dns/avahi/avahi-0.6.30-r1.ebuild
net-dns/avahi/avahi-0.6.30-r3.ebuild
net-libs/gtk-vnc/gtk-vnc-0.4.3-r1.ebuild
net-libs/gtk-vnc/gtk-vnc-0.4.4.ebuild
net-libs/gtk-vnc/gtk-vnc-0.5.0-r1.ebuild
net-libs/gtk-vnc/gtk-vnc-0.5.0.ebuild
net-misc/spice-gtk/spice-gtk-0.11.ebuild
net-misc/spice-gtk/spice-gtk-0.12.ebuild
net-misc/spice-gtk/spice-gtk-0.7.159.ebuild
net-misc/spice-gtk/spice-gtk-0.8.ebuild
net-p2p/eiskaltdcpp/eiskaltdcpp-2.2.6.ebuild
net-p2p/eiskaltdcpp/eiskaltdcpp-2.2.7.ebuild
net-p2p/eiskaltdcpp/eiskaltdcpp-9999.ebuild
sci-mathematics/gretl/gretl-1.9.7.ebuild
sci-mathematics/gretl/gretl-1.9.8.ebuild
www-client/dwb/dwb-2012.02.01.ebuild
www-client/dwb/dwb-2012.05.11.ebuild
www-client/dwb/dwb-9999.ebuild
www-client/opera/opera-11.64.1403.ebuild
www-client/opera/opera-12.00.1448.ebuild
www-client/opera/opera-12.00.1450.ebuild
www-client/opera-next/opera-next-12.00.1440.ebuild
www-client/opera-next/opera-next-12.00.1441.ebuild
www-client/opera-next/opera-next-12.00.1445.ebuild
www-client/opera-next/opera-next-12.00.1448.ebuild
www-client/opera-next/opera-next-12.00.1450.ebuild
www-client/uget/uget-1.8.0.ebuild
www-client/uget/uget-9999.ebuild
www-client/uzbl/uzbl-2011.07.17.ebuild
www-client/uzbl/uzbl-2011.07.25.ebuild
www-client/uzbl/uzbl-2011.10.01.ebuild
www-client/uzbl/uzbl-2011.11.28.ebuild
www-client/uzbl/uzbl-9999.ebuild
x11-themes/light-themes/light-themes-0.1.8.29.ebuild
x11-themes/light-themes/light-themes-0.1.8.32.ebuild
x11-themes/light-themes/light-themes-0.1.9.1.ebuild
email Follow the discussionReplies 35 repliesReplies Make a reply

Replies

#1 Alexandre Rostovtsev
June 10th, 2012 - 12:00 am ET | Report spam
On Sun, 2012-06-10 at 04:38 +0200, hasufell wrote:
Bug #420433 lately introduced the discussion again if and when we should
support older (deprecated) toolkit versions.

As for the named bug it may make sense to support it, cause the gtk3
useflag would lead to different (reduced) functionality of that package.
(but that shall not be the discussion here)

Generally I think gtk3 useflags should be avoided and only be a
workaround during migration to gtk+:3. Optimally gtk+:3 should always be
forced when available and not leading to major issues.
On the other hand... if gtk+:3 implementation is broken I would suggest
to simply force gtk+:2 without any gtk3 useflag. So we have ONE working
toolkit version.

Introducing stuff like gtk3 useflag will let users think this is about
choice, but it's actually not (gtk+:2 is not being developed any longer
afais).

Would it make sense to add a tracker for packages currently using gtk3
useflag, so this will not become a habit and only be a workaround?



The Gnome team's recommendation is to avoid gtk3 or gtk2 USE flags.

For libraries, if possible, try splitting gtk2 and gtk3 support into
different slots (see net-libs/webkit-gtk for an example; the gtk2-based
versions have -r2xx revision numbers and go in slot 2, while the
gtk3-based versions have -r3xx revision numbers and go in slot 3).
Unfortunately, for a few libraries, this splitting is difficult to do in
a sane and maintainable manner, so then a gtk3 USE flag could be the
least bad solution.

For applications, just pick one version of gtk. If a particular version
works better, use only that one (e.g. if building an application against
gtk3 would result in reduced functionality or introduce crashes, or if
upstream calls it experimental, you should probably stick with gtk2 for
now). If the results of building against gtk2 or gtk2 are mostly
equivalent, I suggest only building against gtk3, because gtk2 is
basically legacy code that doesn't get much attention from gtk upstream.

-Alexandre

Similar topics