Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=710917 --- Comment #4 from Robin Lee <robinlee.sysu@xxxxxxxxx> 2011-06-21 14:17:18 EDT --- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Here is my review for this > > > - rpmlint output is clean > > > > > > ? The package bundles the rtmidi library. Normally, we do not allow bundled > > > libraries in Fedora. However as far as I remember, the last time we checked > > > (1-2 years ago?), the rtmidi library was not packagable, so we allowed this as > > > an exception. Did you look into this? > > rtmidi library is still not dynamically linkable. > > > > No it is not. But > 1- It can be made dynamically linkable. But this might conflict with upstream's > intentions. It should better be asked upstream. > 2- Even if it should remain static, should we not package it separately? I am > not sure if bundling is the correct solution. > I think we are not necessary to talk about the issue of this library here: 1. The guide line says 'A package should not include or build against a local copy of a library that *exists* on a system.' Since RtMidi doesn't exist in Fedora, we can consider it just part of this very work. 2. We should not choose a shared library name for RtMidi upstream, who doesn't intend to make it a shared library. I will ask RtMidi upstream for this issue later. > > > > > > * The license tag as GPLv3+ is correct, except the bundled rtmidi library is > > > MIT. Depending on the unbundling situation we might need to add MIT to the > > > license tag. > > According to > > https://fedoraproject.org/wiki/Licensing/FAQ#How_should_I_handle_multiple_licensing_situations.3F > > , since MIT is compatible with GPL, so only GPL is needed listed. > > > > I know about that guideline, which contradicts what FE-Legal says. I was > thinking exactly the same way you are, and a package reviewer asked me to list > all the licenses separately in the license tag of a package that all code was > compiled into a single binary. > > I asked FE-Legal, quoting the link you gave above, and they told me to list all > the licenses separately: > > https://www.redhat.com/archives/fedora-legal-list/2009-December/msg00029.html > I think we can try to ask FPC to make the guidelines for this situation more explicit and detailed. > > > > > > > ? Should we build this package with jack support? Jack is the most common sound > > > server used in audio production type applications. > > I prefer upstream default setting. > > After you build the "vmpk" binary, you can pass some additional flag to cmake > to build another binary with jack support, you can even call the second binary > vmpk-jack. Please see the README and CMakeLists.txt files. > > $ cmake . -DRTMIDI_DRIVER=JACK -DPROGRAM_NAME=vmpk-jack > > Compiling with jack support is important, since we have a large collection of > jack-supporting programs, and this will allow "vmpk" to communicate with all of > them. jack is pretty much the standard sound server in Linux audio production > software. Do you have an argument why compiling with jack support will be bad > for Fedora users? OK. Actually I don't have a strong position. SRPM URL: http://cheeselee.fedorapeople.org/vmpk-0.4.0-2.fc15.src.rpm Change: - Use JACK driver instead of ALSA -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review