Bug 215165 - Review Request: audacious-plugins - Plugins for the Audacious media player
Review Request: audacious-plugins - Plugins for the Audacious media player
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Parag AN(पराग)
Fedora Package Reviews List
:
Depends On: 214818
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-11-11 14:29 EST by Ralf Ertzinger
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-26 15:12:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ralf Ertzinger 2006-11-11 14:29:19 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
Description:

Audacious is a media player that currently uses a skinned
user interface based on Winamp 2.x skins. It is based on ("forked off")
BMP.
This package provides essential plugins for audio input, audio output
and visualization.
Comment 1 Ralf Ertzinger 2006-11-14 15:33:16 EST
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.
Comment 2 Parag AN(पराग) 2006-11-15 23:43:26 EST
I dont think you need Obsoletes tag for subpackages -arts, -jack, -esd. Because
they are throwing a rpmlint error.
Comment 3 Ralf Ertzinger 2006-11-16 03:42:53 EST
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:?
Comment 4 Parag AN(पराग) 2006-11-16 04:07:40 EST
(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.
ok
> 
> Do you refer to the message that the subpackages have Obsoletes:, but no
Provides:?

Yes.
Comment 5 Ralf Ertzinger 2006-11-16 04:26:25 EST
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.
Comment 6 Dominik 'Rathann' Mierzejewski 2006-11-16 21:41:38 EST
(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.
Comment 7 Matthias Saou 2006-11-17 05:20:11 EST
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 ;-)
Comment 8 Parag AN(पराग) 2006-11-17 06:09:44 EST
Ok. Based on you comment i am going to review this package now.
Comment 9 Parag AN(पराग) 2006-11-17 06:41:16 EST
(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
Review
+ 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.
8ac7f73da7432e1ffed6c2b9b0fced8c  audacious-plugins-fedora-1.2.2.tar.gz
+ 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,
   audacious-plugins-esd,audacious-plugins-pulseaudio
+ 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.

SHOULD:-
  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.
like
/usr/lib/audacious
/usr/lib/audacious/Container
/usr/lib/audacious/Effect
/usr/lib/audacious/General
/usr/lib/audacious/Input
/usr/lib/audacious/Output
/usr/lib/audacious/Visualization
Make it own by audacious-plugins
Comment 10 Parag AN(पराग) 2006-11-17 06:56:41 EST
Matthias Saou,
      What do you think is above question is valid or should i approve package
as it is?
Comment 11 Ralf Ertzinger 2006-11-17 07:07:22 EST
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 :)
Comment 12 Matthias Saou 2006-11-17 07:25:08 EST
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 ;-)
Comment 13 Ralf Ertzinger 2006-11-17 07:31:12 EST
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.

Ugly, that.
Make audacious-libs own the plugin-dirs?
Comment 14 Matthias Saou 2006-11-17 08:16:22 EST
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?
Comment 15 Ralf Ertzinger 2006-11-17 09:05:25 EST
You're right, I forgot that (splitting off audacious-libs solved the build time
deps, however).

But even the explicit dependency does not guarantee removal in the right order,
or does it?

Any bright ideas on that?
Comment 16 Parag AN(पराग) 2006-11-19 23:54:58 EST
Ralf,
    Got any working solution?may be then you can do make a-p own audacious-libs.
Just a thought.
Comment 17 Ralf Ertzinger 2006-11-20 03:19:01 EST
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.
Comment 18 Ralf Ertzinger 2006-11-21 04:54:57 EST
New audacious and audacious-plugins packages at
http://www.skytale.net/files/audacious/
Moves /usr/lib/audacious into audacious-plugins, and adds a patch for cdaudio.
Comment 19 Parag AN(पराग) 2006-11-21 05:24:51 EST
Unable to download files
Comment 20 Parag AN(पराग) 2006-11-21 07:21:51 EST
Ok got the access.
I think packaging is OK now.
APPROVED from me but do anyone have still any objections?
Comment 21 Dominik 'Rathann' Mierzejewski 2006-11-21 08:13:57 EST
fluidsynth alsa-midi plugin is still missing, see comment #6.
Comment 22 Ralf Ertzinger 2006-11-21 12:46:54 EST
fluidsynth added
Comment 23 Parag AN(पराग) 2006-11-21 23:00:04 EST
where? why are you not posting updated direct download links here?
Comment 24 Ralf Ertzinger 2006-11-22 13:42:56 EST
It's at the same place all the other versions were, posted several times though
this review. I thought that was kind of evident.

http://www.skytale.net/files/audacious/audacious-plugins-1.2.2-0.8.sky.src.rpm
http://www.skytale.net/files/audacious/audacious-plugins.spec
Comment 25 Parag AN(पराग) 2006-11-22 23:18:39 EST
Thanks APPROVED.
Comment 26 Ralf Ertzinger 2006-11-24 07:02:54 EST
Thanks.

Note You need to log in before you can comment on or make changes to this bug.