Description of problem: There was an old package, in "Fedora Extras", called xmms-skins which provided assorted "faceplates" for xmms. audacious is just fine with those and actually even shows them up in its "look" browser in options. There is one catch. xmms-skins package has a dependency on xmms so things are getting unhappy if you would try to keep only the former while replacing the later. If there is no repackaged audacious-skins then at least audacious could have 'xmms' in "Provides" and that would smooth over the issue.
audacious should not Provide: xmms, as it really isn't xmms compatible on a technical level any more (it certainly looks and feels very similar, but the underlying tech has diverved quite a bit). So I'd rather solve this in a different way. Maybe xmms-skins could drop it's dependency on xmms, or xmms and audacious have to get a virtual Provide: which xmms-skins could Require:
> audacious should not Provide: xmms ... I was merely suggesting an "easy workaround with a minimum churn". Surely xmms-skins could use a bit of touch up to be more "universal" and not only in packaging. OTOH they are already there and they work but possibly upstream has something more up to date.
Adding Provides: xmms to audacious could quite possibly have unforseen consequences, as several other packages (real xmms plugins, mostly), Require: xmms, so audacious could get pulled in to satisfy a depencency it can not really provide. Thus my argument for a virtual provides that just covers skin compatibility.
I think the best would be to have both xmms and audacious have a common virtual provides that the xmms-skins package could be changed to require. I suggest something like "xmms-gui" or similar. From the comments above, I'm assuming audacious already searches in /usr/share/xmms/Skins by default, so the only other change needed would be to add /usr/share/xmms and /usr/share/xmms/Skins to be owned by xmms-skins in order to not have any unowned parent directories. Thoughts? If this sounds good, then someone just needs to file two reports against xmms and audacious in order to get the "Provides:" added, then I can update xmms-skins.
> I suggest something like "xmms-gui" or similar. Technically those "skins" are not GUI but only a bunch of pictures so maybe "xmms-faceplates", or something of that sort, would be more suitable? Yes, audacious goes "by itself" to /usr/share/xmms/Skins directory if available. Those pictures do have "xmms" plastered all over but that does not seem to be that important.
(In reply to comment #5) > > I suggest something like "xmms-gui" or similar. > > Technically those "skins" are not GUI but only a bunch of pictures so maybe > "xmms-faceplates", or something of that sort, would be more suitable? I'm not saying xmms-skins provides that, I'm saying that xmms and audacious both provide the Winamp/XMMS like GUI, so they could have the common virtual provide called "xmms-gui" without even bringing skins into the discussion (yet). The skins package(s) would then require "xmms-gui".
That's fine with me.
I've updated the requirement, and took the liberty of rebuilding both xmms and audacious in devel with the new "Provides: xmms-gui", since the F-11 freeze is in two days. I hope you won't mind.