Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 420493 (use_gtk3)

Summary: [tracker] ebuilds using gtk3 or similar useflags (talk on ML)
Product: Gentoo Linux Reporter: Julian Ospald <hasufell>
Component: New packagesAssignee: Julian Ospald <hasufell>
Status: RESOLVED WORKSFORME    
Severity: normal CC: gnome, nikoli, qa
Priority: Normal Keywords: Tracker
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=489810
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 420433, 420525, 420527, 420529, 420531, 420533, 420535, 420537, 420539, 420541, 420543, 420545, 420547, 420549, 420551, 420553, 420555, 420557, 420559, 420561, 420563, 420565, 420567, 420569, 431828, 497144    
Bug Blocks:    

Description Julian Ospald 2012-06-10 14:18:25 UTC
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.
Comment 1 Doug Goldstein (RETIRED) gentoo-dev 2012-06-11 02:55:23 UTC
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.
Comment 2 Julian Ospald 2012-06-11 09:23:55 UTC
(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.
Comment 3 Gilles Dartiguelongue (RETIRED) gentoo-dev 2012-06-23 12:41:27 UTC
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 ?
Comment 4 Julian Ospald 2012-06-23 18:17:03 UTC
(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.
Comment 5 Julian Ospald 2014-04-04 18:12:12 UTC
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.
Comment 6 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2014-04-04 18:27:31 UTC
It is ongoing.
Comment 7 Julian Ospald 2014-04-04 18:30:25 UTC
(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.