Fedora Merge Review: libmusicbrainz http://cvs.fedora.redhat.com/viewcvs/devel/libmusicbrainz/ Initial Owner: alexl
New Initial Owner: bnocera
I'm maintaining libtunepimp, would you like to comaintain these together? (If so, I can help review this)
libtunepimp is deprecated, isn't it? I'd be more than happy to have a libmusicbrainz co-maintainer, but I'm not really interested in maintaining a deprecated library :)
> libtunepimp is deprecated, isn't it? news to me, amarok uses it (afaik, amarok2 will too).
http://musicbrainz.org/doc/libtunepimpDownload says: "<!> libtunepimp uses the old RDF WebService and should not be used in new development. See WebService for more details."
doh, thanks.
I did a full review on this package. Everything seems fine except * docs/mb_howto.txt should be included among %doc, or maybe in devel's %doc * the examples directory should be included in devel's %doc Other than these two things the package yields Fedora Guidelines. A question: Isn't it time to rename this package as libmusicbrainz2 and call libmusicbrainz3 as libmusicbrainz? Is there a particular reason why this is not done yet?
ping?
wrt renaming? I guess it could be considered (for F-11), Bastien what do you think? (I'll take care of the other items from comment #7)
Or maybe we can just libmusicbrainz3 -> libmusicbrainz (and EOL existing libmusicbrainz/libtunepimp).
Spoke too soon perhaps, seems there's quite a bit of stuff still depending on libmusicbrainz(2): libtunepimp(1) sound-juicer k3b(1) gstreamer-plugins-bad kdemultimedia(1) rhythmbox(2) (1) I do these, and it wouldn't break my heart if libmusicbrainz support went away. (2) Wierd, rhythmbox seems to link to *both* libmusicbrainz/libmusicbrainz3.
I don't see the point of renaming the library: - it's not user-facing - libmusicbrainz (2.x) will soon be useless when MB turn off their old servers - libmusicbrainz3 is what it's called upstream Sound-juicer and rhythmbox are already ported to libmusicbrainz3 and use both.
(In reply to comment #12) > - libmusicbrainz3 is what it's called upstream I don't think that is the case anymore: http://musicbrainz.org/doc/libmusicbrainzDownload But if it is going to cause lots of trouble we can leave things as are.
OK, new proposal: EOL libmusicbrainz (libtunepimp)
I see no objections, I'll move forward on EOL'ing these asap. A libmusicbrainz3 pkg rename can be reconsidered at a later date.
Damn, looks like the new kscd in kdemultimedia-4.2.x has a hard-dep on libmusicbrainz... the best laid plans go awry.
listen also still requires the old libmusicbrainz: bug #486523 please restore.
I don't think it is removed. Please see: https://www.redhat.com/archives/fedora-devel-list/2009-February/msg01486.html
It was removed from last night's rawhide, at least temporarily: http://koji.fedoraproject.org/mash/rawhide-20090219/logs/repodiff Removed package libmusicbrainz Removed package libtunepimp
OK, looks like they were restored in CVS. I'm going to rebuild them for rawhide now, since it seems that Jesse unblocked them from rawhide. Hopefully they'll make it into tomorrow's rawhide.
I guess if they are unblocked, it'll revert to the F-10 version of libmusicbrainz and libtunepimp, so it should at least fix the broken deps. Look like libtunepimp doesn't rebuild from source in any case: http://koji.fedoraproject.org/koji/taskinfo?taskID=1141627
Could you folks update the package according to comment #7 so we can close the merge review? I also noticed that there is one occurrence of rm that should be converted to %{__rm} for macro consistency.
ping? no one wants to fix the trivial things I pointed in comments #7 and #22 ?
(In reply to comment #22) > I also noticed that there is one occurrence of rm that should be converted to > %{__rm} for macro consistency. Done (In reply to comment #7) > I did a full review on this package. Everything seems fine except > > * docs/mb_howto.txt should be included among %doc, or maybe in devel's %doc Done > * the examples directory should be included in devel's %doc Done > Other than these two things the package yields Fedora Guidelines. > > A question: Isn't it time to rename this package as libmusicbrainz2 and call > libmusicbrainz3 as libmusicbrainz? Is there a particular reason why this is not > done yet? This would be a pretty pointless shuffling of package names.
Thanks! The %doc docs/mb_howto.txt examples/README.examples examples/*.c examples/*.cpp line must come after %defattr(-,root,root,-) Afaict this is the only outstanding issue left.
Done in -10
Yay! All good. ------------------------------------------------------ This merge review (libmusicbrainz) is APPROVED by oget ------------------------------------------------------ Closing.