Summary: | media-sound/audacious-3.2.3: strange gtk vs gtk3 USE flag exclusion | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
Component: | Current packages | Assignee: | 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
2012-06-09 20:19:21 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. (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. (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. (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) 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...) Fixed in audacious(-plugins)-3.2.3. gtk+:3 support dropped for now. Thanks :) *** Bug 424639 has been marked as a duplicate of this bug. *** (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. 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. |