gtk3 and similar useflags (such as gtk2 or "deprecated" when it's related to gtk+ slot) are undesired proposed course of action: 1) Force gtk+:3 whenever possible 2) Force gtk+:2 when gtk+:3 implementation is available, but broken 3) 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) 4) If you must support both slot 2 and 3 (and hence introduce something like gtk3 useflag) for a regular package consider this a workaround and try to avoid stabilization.
You really have not addressed all the situations here. Say I have package app-misc/foo-2.4.9, it supports GTK 2 or 3 based on a configure switch. It supports a Firefox plugin when built with GTK 2 but not hen built with 3. The 3 proposed solutions don't provide for a reasonable way for users to install the package since portage will show the highest slot when they emerge. Now app-misc/foo-2.4.9 depends on dev-libs/foo-2.4.9, which can be built with GTK 2 or 3. Based on the proposed suggestions, we would skip GTK 3 support which now means Gentoo users couldn't get full support from app-misc/foo. Or creating 2 SLOTs requiring the maintainer of dev-libs/foo to maintain 2 versions of the same package that differ by 2 bytes. (2 -> 3 in the SLOT variable and the ./configure script) Another solution would be to require each package that installs libraries to double compile to install the GTK 2 and 3 versions. Which is exactly the situation we have now for several packages using the gtk3 use flag to enable the double compile. You really should bring this up on the gentoo-dev ML for more discussion.
(In reply to comment #1) > You really have not addressed all the situations here. Say I have package > app-misc/foo-2.4.9, it supports GTK 2 or 3 based on a configure switch. It > supports a Firefox plugin when built with GTK 2 but not hen built with 3. > The 3 proposed solutions don't provide for a reasonable way for users to > install the package since portage will show the highest slot when they > emerge. > > Now app-misc/foo-2.4.9 depends on dev-libs/foo-2.4.9, which can be built > with GTK 2 or 3. Based on the proposed suggestions, we would skip GTK 3 > support which now means Gentoo users couldn't get full support from > app-misc/foo. Or creating 2 SLOTs requiring the maintainer of dev-libs/foo > to maintain 2 versions of the same package that differ by 2 bytes. (2 -> 3 > in the SLOT variable and the ./configure script) > > Another solution would be to require each package that installs libraries to > double compile to install the GTK 2 and 3 versions. Which is exactly the > situation we have now for several packages using the gtk3 use flag to enable > the double compile. Thanks for the addition. Yes I know there may be situations where the proposed solutions are not sufficient. That is dicussed in the bugs then. But I wanted to have an overview of the situation since the gtk useflag was not meant to be slot-specific in the first place. Other solutions may be valid, but are still a migration issue, so I add them here. > > You really should bring this up on the gentoo-dev ML for more discussion. It was already before I opened this bug.
I really don't know why you open this issue while the situation was clearly explained by the gnome team a couple of times already. All gnome maintained ebuilds already follow the policy with care to still allow relatively easy maintenance, so what exactly do you expect ?
(In reply to comment #3) > I really don't know why you open this issue while the situation was clearly > explained by the gnome team a couple of times already. > > All gnome maintained ebuilds already follow the policy with care to still > allow relatively easy maintenance, so what exactly do you expect ? This is a tracker and used for tracking possible misuse of gtk3 useflag, discussion is on the ML. You may ignore this or mark my bugs assigned to you (if there is one) as INVALID/WONTFIX if the rationale does not apply or if you disagree with it.
I cannot make any sense out of the council log and the gnome team didn't tell me anything that will help me here, so closed as WORKSFORME. I don't have the time to hunt for answers all day long.
It is ongoing.
(In reply to Tom Wijsman (TomWij) from comment #6) > It is ongoing. Good luck then, please open a new tracker if you need one, I don't want to get any mails about this.