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

Bug 420433

Summary: media-sound/audacious-3.2.3: strange gtk vs gtk3 USE flag exclusion
Product: Gentoo Linux Reporter: Pacho Ramos <pacho>
Component: Current packagesAssignee: Jeff (JD) Horelick (RETIRED) <jdhore>
Status: RESOLVED FIXED    
Severity: enhancement CC: gnome, openhs, sound
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 420493    

Description Pacho Ramos gentoo-dev 2012-06-09 20:19:21 UTC
Reading ebuild I don't understand what is "gtk" USE flag really doing. Even if I would prefer it to simply move to gtk3 only support (bug 374057), could this at least be converted to "gtk gtk3" combination simply enable gtk3 support?

Thanks


Reproducible: Always
Comment 1 Jeff (JD) Horelick (RETIRED) gentoo-dev 2012-06-10 01:59:16 UTC
Basically, on audacious 3.2, some plugins disable themselves because they do not work with gtk+:3. The choice there is basically...Do you want gtk+:3 support or all plugins working? (choose only one)

I do NOT think backporting the upstream patch to convert the other plugins to gtk+:3 is a remotely good idea.

This will be fixed soon as audacious 3.3 requires gtk+:3 so...

I suppose I COULD drop the gtk USE flag and have gtk2 implicitly and have gtk3 as a USE flag, but I don't like showing up in someone's --newuse for what is simply a semantical change.

Also, I showed this situation to a friend of mine who is simply a user and has never written an ebuild and it makes perfect sense to him....

Closing as WONTFIX.
Comment 2 Julian Ospald 2012-06-10 02:17:56 UTC
(In reply to comment #1)
> Basically, on audacious 3.2, some plugins disable themselves because they do
> not work with gtk+:3. The choice there is basically...Do you want gtk+:3
> support or all plugins working? (choose only one)

That's a valid argument for that useflag.

> 
> I do NOT think backporting the upstream patch to convert the other plugins
> to gtk+:3 is a remotely good idea.
> 
> This will be fixed soon as audacious 3.3 requires gtk+:3 so...

That part I don't understand. Especially if you plan to support/stabilize these versions longer (which is what you want if I remember correctly).
If not, then we should rather go for quick stabilization of the upcoming 3.3 release and drop the problematic 3.2 versions completely.

> 
> I suppose I COULD drop the gtk USE flag and have gtk2 implicitly and have
> gtk3 as a USE flag, but I don't like showing up in someone's --newuse for
> what is simply a semantical change.
> 

I just think we should at least tell the user about this situation, either via elog or via masking gtk3 useflag. I will see if it makes sense after I have investigated what plugins are broken etc.
Comment 3 Jeff (JD) Horelick (RETIRED) gentoo-dev 2012-06-10 03:21:48 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > 
> > I do NOT think backporting the upstream patch to convert the other plugins
> > to gtk+:3 is a remotely good idea.
> > 
> > This will be fixed soon as audacious 3.3 requires gtk+:3 so...
> 
> That part I don't understand. Especially if you plan to support/stabilize
> these versions longer (which is what you want if I remember correctly).
> If not, then we should rather go for quick stabilization of the upcoming 3.3
> release and drop the problematic 3.2 versions completely.

3.2 is being labelled as sort of LTS by upstream since it is the last version to support gtk+:2 so for those (in some cases, many) people running MATE or LXDE (I think) or XFCE, it still fits well with their desktop environment. Applying the patch to make everything work with gtk+:3 and removing gtk+:2 support makes keeping 3.2 a bit pointless.

> 
> > 
> > I suppose I COULD drop the gtk USE flag and have gtk2 implicitly and have
> > gtk3 as a USE flag, but I don't like showing up in someone's --newuse for
> > what is simply a semantical change.
> > 
> 
> I just think we should at least tell the user about this situation, either
> via elog or via masking gtk3 useflag. I will see if it makes sense after I
> have investigated what plugins are broken etc.

I think package.use.masking the gtk3 USE flag might be best here since it appears to me like some plugins aren't disabled if gtk+:3 is used at compile time, but the GUI's for setting preferences isn't built thus causing some possibly weird cases.
Comment 4 Pacho Ramos gentoo-dev 2012-06-10 09:40:17 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > 
> > > I do NOT think backporting the upstream patch to convert the other plugins
> > > to gtk+:3 is a remotely good idea.
> > > 
> > > This will be fixed soon as audacious 3.3 requires gtk+:3 so...
> > 
> > That part I don't understand. Especially if you plan to support/stabilize
> > these versions longer (which is what you want if I remember correctly).
> > If not, then we should rather go for quick stabilization of the upcoming 3.3
> > release and drop the problematic 3.2 versions completely.
> 
> 3.2 is being labelled as sort of LTS by upstream since it is the last
> version to support gtk+:2 so for those (in some cases, many) people running
> MATE or LXDE (I think) or XFCE, it still fits well with their desktop
> environment. Applying the patch to make everything work with gtk+:3 and
> removing gtk+:2 support makes keeping 3.2 a bit pointless.
> 

Then, why not make 3.2 gtk2 only and newer gtk3 versions? Also, I still don't see why it's not possible to make gtk+gtk3 USE flags behave like any other ebuilds in the tree -> enable gtk3 support. I don't see any other package making them exclusive (this also makes audacious uninstallable by default when using gnome profile, that enables both to get proper support for both toolkits

Also, only having a gtk3 USE flag also looks ok to me (well, audacious is not so big to rebuild)
Comment 5 Pacho Ramos gentoo-dev 2012-06-10 09:49:43 UTC
Anyway, I think that in this case it's better to make long term release gtk2 only instead of backporting patches (maybe if upstream backports that patches in the future...)
Comment 6 Jeff (JD) Horelick (RETIRED) gentoo-dev 2012-06-10 18:46:39 UTC
Fixed in audacious(-plugins)-3.2.3. gtk+:3 support dropped for now.
Comment 7 Pacho Ramos gentoo-dev 2012-06-10 19:15:56 UTC
Thanks :)
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2012-07-03 20:44:24 UTC
*** Bug 424639 has been marked as a duplicate of this bug. ***
Comment 9 Rafał Mużyło 2012-07-04 01:24:26 UTC
(In reply to comment #1)
> Basically, on audacious 3.2, some plugins disable themselves because they do
> not work with gtk+:3. The choice there is basically...Do you want gtk+:3
> support or all plugins working? (choose only one)
> 
Seems audacious has a problem, but not with gtk3.

While I disagreed with *previous* audacious maintainer on several occasions, he was still (at the time) a member of upstream and he said, that 3.2 series are completely functional with gtk3.

The comment in audacious 3.2.3 ebuild in incorrect - I've built
media-sound/audacious  USE="chardet gtk3 nls session -gtk"
media-plugins/audacious-plugins  USE="aac alsa cdda ffmpeg flac fluidsynth gnome gtk3 ipv6 libnotify libsamplerate midi mms mp3 mtp nls pulseaudio scrobbler sdl sid sndfile vorbis wavpack -adplug -bs2b -cue -gtk -jack -lame -oss"

and the only plugins disabled were the ones disabled by useflags - statusicon was not only built but also working.
Comment 10 Jeff (JD) Horelick (RETIRED) gentoo-dev 2012-07-05 17:38:42 UTC
OK, here's the current state of this: audacious-3.2.* is staying gtk2-only, upstream has dropped gtk2-support in audacious-3.3* (the beta is in the tree) and since it's in beta, it's probably fairly close to release so that'll be where you get gtk3 support.