These packages make use of gtk3 useflag which indicates that there are issues of migration to gtk+:3. Gtk3 and similar useflags should be avoided. Adding to tracker. Please have a look.
(In reply to comment #0) > These packages make use of gtk3 useflag which indicates that there are > issues of migration to gtk+:3. The package supports both the GTK 2.x and 3.x version of Audacious. Forcing the use of GTK 3.x would disable support for Audaciuous 2.x which I rely on myself. What do you propose?
Alright, this relies on the gtk flag handling of audacious too. I would suggest to use two slots for this package as mentioned in the tracker bug (and force one toolkit version and audacious versions for each slot).
(In reply to comment #2) > I would suggest to use two slots for this package as mentioned in the > tracker bug (and force one toolkit version and audacious versions for each > slot). If I make two slots for version 0.7.2 of mp3splt-gtk that results in two files called mp3splt-gtk-0.7.2.ebuild, correct? How can I make two slots for the very same version? What do have in mind?
(In reply to comment #3) > (In reply to comment #2) > > I would suggest to use two slots for this package as mentioned in the > > tracker bug (and force one toolkit version and audacious versions for each > > slot). > > If I make two slots for version 0.7.2 of mp3splt-gtk that results in two > files called mp3splt-gtk-0.7.2.ebuild, correct? How can I make two slots > for the very same version? What do have in mind? Hmm, I'm actually not sure if this would be a misuse of slotting. Are slots expected to be always installable simultaneously? Let's drop that proposal for now. However, the current ebuilds do not force "gtk3" useflag of version 3.2.x of audacious. what I mean: gtk3? ( x11-libs/gtk+:3 audacious? ( || ( =media-sound/audacious-3.1* =media-sound/audacious-3.2*[gtk3] ) ) ) Maybe we should rather wait what happens to audacious packages.
gtk3 has been disabled for audacious-3.2.3, so only audacious-3.2.2-r1 (which has not been modified, cause it's stabilized) and 3.1* still supports gtk3. bug 420433 so I would propose: gtk3? ( x11-libs/gtk+:3 audacious? ( || ( =media-sound/audacious-3.1* =media-sound/audacious-3.2.2-r1[gtk3] ) ) ) This still looks like a mess. Please add comments to your ebuild wrt to these bugs.
and don't close this bug yet, so we can figure out if we are able to drop gtk3 useflag some time later
There is nothing wrong with using gtk3 useflag, as long as both gtk2 and gtk3 are supported by this package.
(In reply to comment #7) > There is nothing wrong with using gtk3 useflag, as long as both gtk2 and > gtk3 are supported by this package. That support will break/is broken, cause audacious is in the process of removing gtk3 useflag in favor of enforcing one of both slots depending on the state of the release. As you can see this will result in pretty weird version-dependencies.
current stable audacious simply uses gtk+:3 and doesn't support gtk+:2 futhermore older than current stable audacious versions only compile with certain USE flags, and are broken due to it's dependencies like libcdio changing API, to a point that older audacious versions should be treecleaned anyday now i don't know mp3splt-gtk got to this, but the package used to be fine... :/
why did you close the bug, when it's not handled?
I don't have the time to work on QA if I have neither support from QA, council or gnome team.
