Bug 2182

Created attachment 808 [details]
source RPM created from the spec file

Hi Chen!

I'm no reviewer, but perhaps I can help a little.

The first step is to get your request in shape a little. Take a look at http://rpmfusion.org/Contributors#head-0df093adde5a77a5e0569b2460ff49d078007ae3, and try to fix up this accordingly. This includes:
- Fix the subject line
- URL:s to spec file and SRPM. The version you have attached now are fine ATM, but next don't attach them.  Provide URL:s instead.
- Why this package should got to rpmfusion (i, e., why not Fedora).
- The output from rpmlint, according to link
- Mention if it's your first package, and if you thus need s sponsor. If so, make this package block bug 30 NEEDSPONSORS
- Make it block bug #2 RF_NEW

So, I think this package can go into Fedora, but the "To enable all functionality, the following packages are required:" part will have to be removed, you cannot give a list of patent-encumbered packages in Fedora. For the stuff which is actually in Fedora, IMHO you should just make it hard Requires. Without at least some of the listed packages, soundKonverter will not work at all.

Now if you put the package into RPM Fusion Free, you can also make the stuff in RPM Fusion Free hard Requires, if you put it into RPM Fusion Nonfree, you can also make the stuff in RPM Fusion Nonfree hard Requires. I guess RPM Fusion will also be more tolerant of a list of additional dependencies one can install than Fedora.

Considering all of the above, I think the best solution would be to put the package in Fedora with just Requires: the dependencies which are in Fedora and without the "To enable all functionality, the following packages are required:" blurb in the package description, which is best put somewhere else (RPM Fusion wiki?).

@Alec and Kevin: Thanks for both of your answers!

@Alec: I'll fix the bug according to the link you posted.

@Kevin: I see. So basically hard requires the packages available from the repo it should go in. Based on what you said, I'll try submitting it to Fedora first. If they reject it for some reason, I'll try to get it in RPMFusion.

@Kevin: Actually, I think it would be better to submit soundkonverter to RPMFusion. In the source code, the plugins directly depend on the codecs, which means that instead of having one package, there will be two (soundkonverter in Fedora and soundkonverter-freeworld in RPMFusion).

Here's the new spec:

https://raw.github.com/chenxiaolong/Fedora-SRPMS/master/soundkonverter/soundkonverter.spec

and SRPM:

https://github.com/downloads/chenxiaolong/Fedora-SRPMS/VirtualGL-2.3-6.fc16.src.rpm

> In the source code, the plugins directly depend on the codecs

You mean they need to link against the codec libraries? Then the package needs a BuildRequires for the relevant -devel package(s)! (And the corresponding runtime Requires will be automatically detected in that case and is thus not needed.)

If, on the other hand, they run the codecs' command-line executables, no build-time dependency is needed and the package can go into Fedora.

The line Fedora Legal has drawn so far is that it's OK for a package to check for, e.g., "lame" being installed and run it if it is, and/or to tell the user "cannot encode to the requested format because no suitable encoder was found", but not to say "install lame to encode MP3s". (Whether "error: lame not found" is acceptable is something which hasn't been discussed AFAIK.)

Ahh...okay. The plugins currently run the commands and do not link against the libraries. I'll have to check the source code to see if it asks the user to install patent -encumbered packages though.

Closing due to inactivity, please reopen if you're interested in pursuing this review request.