Red Hat Bugzilla – Bug 215165
Review Request: audacious-plugins - Plugins for the Audacious media player
Last modified: 2007-11-30 17:11:48 EST
Spec URL: http://www.skytale.net/files/audacious/audacious-plugins.spec
SRPM URL: http://www.skytale.net/files/audacious/audacious-plugins-1.2.2-0.5.sky.src.rpm
Audacious is a media player that currently uses a skinned
user interface based on Winamp 2.x skins. It is based on ("forked off")
This package provides essential plugins for audio input, audio output
New version to fix missing build requires at http://www.skytale.net/files/audacious/
Needs a newer version of audacious as well, available at the same place.
I dont think you need Obsoletes tag for subpackages -arts, -jack, -esd. Because
they are throwing a rpmlint error.
The obsoletes are necessary, because the old audacious package provided these
extra packages, too, and they need to be replaced on upgrade.
Do you refer to the message that the subpackages have Obsoletes:, but no Provides:?
(In reply to comment #3)
> The obsoletes are necessary, because the old audacious package provided these
> extra packages, too, and they need to be replaced on upgrade.
> Do you refer to the message that the subpackages have Obsoletes:, but no
I am not sure about this one.
For one, there ought to be no packages which Require: audacious-arts, for
example, so there is no gain in the new packages Providing: it.
In addition, if there were any other packages which actually Require: one of the
Obsoleted: packages, they probably need to be rebuilt to match the new codebase,
anyway, so there ought to be a RPM conflict.
So, in conclusion, I think that this specific rpmlint warning can be ignored.
I'd be happy about a third opinion, though.
(In reply to comment #5)
> So, in conclusion, I think that this specific rpmlint warning can be ignored.
> I'd be happy about a third opinion, though.
I think it can be ignored, too.
I have another comment, however. I know it's a matter of preference, but why not
put each BuildRequired package in its own line and sort the list alphabetically?
It makes it easier to spot missing builddeps, for example: fluidsynth-devel and
libglade2-devel. The package doesn't build here without the latter.
Yeah, this also seems correct to me : No need to "provide" the old names, as
they shouldn't have been used other than explicitly (not from other package
requirements). The obsoletes are required though, to provide a clean upgrade
path, and are correct with the last known version.
Please start the review ASAP or let me know if you'd like me to do it instead,
as I'm quite impatient to have this audacious update available ;-)
Ok. Based on you comment i am going to review this package now.
(In reply to comment #7)
> Yeah, this also seems correct to me : No need to "provide" the old names, as
> they shouldn't have been used other than explicitly (not from other package
> requirements). The obsoletes are required though, to provide a clean upgrade
> path, and are correct with the last known version.
> Please start the review ASAP or let me know if you'd like me to do it instead,
> as I'm quite impatient to have this audacious update available ;-)
Thanks for testing this package.
Based on above comment
+ package builds in mock (development i386)FC7.
+ rpmlint is silent for SRPM.
+ rpmlint on RPMs is not silent but as per above comments in bugzilla they
can be ignored.
+ source files match upstream.
+ package meets naming and packaging guidelines.
+ specfile is properly named, is cleanly written
+ Spec file is written in American English.
+ Spec file is legible.
+ dist tag is present.
+ build root is correct.
+ license is open source-compatible. License text included in package.
+ %doc is small; no -doc subpackage required.
+ %doc does not affect runtime.
+ COPYING included in %doc.
+ BuildRequires are proper.
+ %clean is present.
+ package installed properly.
+ Macro use appears rather consistent.
+ Package contains code, not content.
+ no headers or static libraries.
+ no .pc files.
+ no -devel subpackage exists
+ available subpackages are audacious-plugins-jack,audacious-plugins-arts,
+ as subpackages are packaging .so files post and postun called /sbin/ldconfig
+ Used update-desktop-database correctly
+ no .la files.
+ no translations available
- Does NOT owns the directories it creates.
+ no duplicates in %files.
+ file permissions are appropriate.
I saw that some directories are owned in audacious rpm whereas there is no
need to own them by audacious but it should be owned by audacious-plugins.
Make it own by audacious-plugins
What do you think is above question is valid or should i approve package
as it is?
OK, one might argue that a-p should own /usr/lib/audacious, since audacious
itself does not place any files there.
If (and that's a big if) we/I should ever decide to split up a-p into a lot of
tiny subpackages these directories would have to go back to audacious, since no
subpackage could own all of these dirs.
I personally do not care too much about it, but given the choice would leave
things as they are (reduces work for me :)
Since we have audacious requiring audacious-plugins, and audacious-plugins
requiring audacious, I'm not quite sure what the proper solution would be. A
while back, I would have made those dirs owned by both packages, in order to be
100% sure they get rmdir'ed upon removal of both packages (since we don't know
which will be removed last in the same rpm transaction), but I'm not sure this
is compatible with today's packaging guidelines.
You might want to ask on the packaging list or go through the guidelines again ;-)
Erm, audacious Requires: audacious-plugins.
audacious-plugins Requires: libaudacious.so.4 (provided by audacious-libs)
audacious-plugins does not require audacious (circular deps, ugly).
So there is nothing that prevents audacious from being removed while a-p is
still installed as far as I can see.
Make audacious-libs own the plugin-dirs?
I just looked again at audacious.spec :
Requires: audacious-plugins >= 1.2.0
And at audacious-plugins.spec :
Requires: audacious >= 1.2.0
But maybe those two spec files aren't the latest?
You're right, I forgot that (splitting off audacious-libs solved the build time
But even the explicit dependency does not guarantee removal in the right order,
or does it?
Any bright ideas on that?
Got any working solution?may be then you can do make a-p own audacious-libs.
Just a thought.
I think I will make a-p own /usr/lib/audacious. This does not solve the question
which package is to be removed first (audacious or a-p), but at least the
directory structure will be cleanly installable and removable.
Modified packages forthcoming.
New audacious and audacious-plugins packages at
Moves /usr/lib/audacious into audacious-plugins, and adds a patch for cdaudio.
Unable to download files
Ok got the access.
I think packaging is OK now.
APPROVED from me but do anyone have still any objections?
fluidsynth alsa-midi plugin is still missing, see comment #6.
where? why are you not posting updated direct download links here?
It's at the same place all the other versions were, posted several times though
this review. I thought that was kind of evident.