Spec URL: http://www.flyn.org/SRPMS/libdmapsharing3.spec SRPM URL: http://www.flyn.org/SRPMS/libdmapsharing3-2.9.0-1.fc14.src.rpm Description: Libdmapsharing API v3. The package may be installed in parallel with the existing libdmapsharing package.
After looking at "repoquery --whatrequires libdmapsharing", why not upgrade the existing libdmapsharing package in Fedora and port the existing API users to the new API? Instead of introducing a parallel installable package. And frankly, it there's a compelling reason to keep both, it wouldn't hurt to package both libraries in the same src.rpm, especially if headers, libraries and sonames are designed in a way they don't conflict. I think it's overhead to request a review of something that is in Fedora already as an older version.
Note that this would be needed also by Rhythmbox now, which has its DAAP plugin disabled in the rawhide package now, because of the missing dep.
Based on Michael's comments, I am going to mark this report WONTFIX. Since the Rawhide Rhythmbox package has been updated to the version that uses libdmapsharing-2.9+, I will build only this libdmapsharing series for Rawhide. See http://koji.fedoraproject.org/koji/taskinfo?taskID=2772656. Cosimo, can you re-enable the Rhythmbox DAAP plugin once this libdmapsharing build hits Rawhide?
(In reply to comment #3) > Based on Michael's comments, I am going to mark this report WONTFIX. Since the > Rawhide Rhythmbox package has been updated to the version that uses > libdmapsharing-2.9+, I will build only this libdmapsharing series for Rawhide. > See http://koji.fedoraproject.org/koji/taskinfo?taskID=2772656. Cosimo, can you > re-enable the Rhythmbox DAAP plugin once this libdmapsharing build hits > Rawhide? Thanks, I just triggered a DAAP-enabled build in Koji.