# ldd /usr/bin/sound-juicer | grep musicbrainz libmusicbrainz.so.4 => /usr/lib/libmusicbrainz.so.4 (0x00007fa968309000) libmusicbrainz3.so.6 => /usr/lib/libmusicbrainz3.so.6 (0x00007fa9680a8000) That shouldn't happen, it should use either one, but not both. I'll look into it, but feel free to beat me to it :) Thanks
upstream bug report
Upstream closed bug report as "NOTABUG", then, does having this one opened have sense really?
In a sense, there's still a bug that sound-juicer still links to both MB libraries when the ebuild assumes that it only links to one. At the very least, the ebuild should reflect that somehow... Cheers
From my point of view, since both libs are supposed to provide different functionalities, I think that sound-juicer should simply RDEPEND on both, for providing full functionality to our users
Agreed.
+ 09 Mar 2010; Gilles Dartiguelongue <eva@gentoo.org> + sound-juicer-2.26.2.ebuild, sound-juicer-2.28.1.ebuild: + configure says musicbrainz:1 is required and :3 is optional (although + automagic), require both, bug #275798. + Done
Actually, looking well into configure.in shows us that "Find optional MusicBrainz3 and required Musicbrainz2" means that _at least_ musicbrainz2 is required, and optionnally you can have musicbrainz3 instead of it, or both. a bit later in configure.in : if test "$have_mb" = "no" && test "$have_mb3" = "no" ; then AC_MSG_ERROR([Either libmusicbrainz or libmusicbrainz3 needs to be available for sound-juicer to build]) fi when musicbrainz3 is there, musicbrainz2 is not needed so the ebuild should not depend on both.
