Version: 3.5.0 (using KDE KDE 3.5.0) Installed from: RedHat RPMs Compiler: gcc version 3.4.4 20050721 (Red Hat 3.4.4-2) kdemultimedia-3.5.0(rc2) when built --with-akode, installs a bunch of akode*PlayObject.mcopclass files to /usr/lib/mcop overlapping with those that akode(-2.0b3) installs. The problem with kdemultimedia's versions is that they're all installed/used regardless of whether the underlying akode plugins are available/installed or not. The worst offenders: akodeFFMPEGPlayObject and akodeMPEGPlayObject. This may explain the folks whose mp3 playback suddenly stopped working after upgrading from kdemultimedia-3.5.0rc1.
Just looked at svn in kdesupport/akode and it looks like the .mcopclass files have been removed from akode. Hmm... IMO the previous approach was better (including the mcopclass files with akode/plugins) since, AFAICT, the mere presence of the .mcopclass files tells arts that these plugins are available/usable (when in some cases, they're not).
Was removed from akode same day they were moved to kdemultimedia. Before being moved they created a circular dependency.
I see no circular dep (ie akode didn't depend on anything in kde, other than the directory /usr/lib/mcop, but I don't consider that in this case). Besides, it's still problematic for kdemultiemdia to install the mcopclass files for plugins that aren't (necessarily) available. It's mcopclass files have higher preference that most others, and can override other lower-priority, but working, PlayObjects. Am I missing something?
We have at least one example of installing all .mcopclass files causing problems in bug #116885 (ie, there's still a bug here -> REOPENING)
The mcopclass files had to move or else if akode were installed without the akode/arts plugin from kdemultimedia, arts would crash. Thus akode had to depend on the akode/arts plugin in kdemultimedia; a circular dependency. If your akode doesn't support certain file types, then make sure that the kdemultimedia arts/akode plugin doesn't ship the mcopclass files for those file types, patch them, etc.
akodeFFMPEGPlayObject.mcopclass is not installed by kdemultimedia for the same reason. The problem with being included unconditional was why I originally put them under akode plugins. The circular problem was if you had arts and akode but not akode_artsplugin, the mcopclasses would be detected but no plugin was available for playing them. This would crash artsd. Notice that the xine-plugin has the same problem. The mcopclass describes all mimetypes, but if you lack some the xine modules, they will not be able to play. Since allmost all the plugins use the same decoding layer for MPEG (MAD is used by arts, xine and akode), I would assume people had it in aKode if they have it at all.
IMO, A better method to avoid said circular dependancy, would be to ship akode_artsplugin as part of akode.
OK, ignore my last comment... It's just that these recent changes make it a bit more complicated to package non-free separately. I'll think of something.
SVN commit 482639 by carewolf: Detect installed aKode plugins before installing their mcopclasses. BUG:116958 M +13 -5 akode_artsplugin/Makefile.am M +10 -0 configure.in.in --- branches/KDE/3.5/kdemultimedia/akode_artsplugin/Makefile.am #482638:482639 @@ -22,13 +22,21 @@ mcoptypedir = $(libdir)/mcop mcoptype_DATA = akodearts.mcoptype akodearts.mcopclass +if include_akode_mpeg +AKODE_MPEG=akodeMPEGPlayObject.mcopclass +endif + +if include_akode_mpc +AKODE_MPC=akodeMPCPlayObject.mcopclass +endif + +if include_akode_xiph +AKODE_XIPH=akodeXiphPlayObject.mcopclass akodeVorbisStreamPlayObject.mcopclass akodeSpeexStreamPlayObject.mcopclass +endif + mcopclassdir = $(libdir)/mcop mcopclass_DATA = akodePlayObject.mcopclass \ - akodeMPCPlayObject.mcopclass \ - akodeMPEGPlayObject.mcopclass \ - akodeXiphPlayObject.mcopclass \ - akodeVorbisStreamPlayObject.mcopclass \ - akodeSpeexStreamPlayObject.mcopclass + $(AKODE_MPC) $(AKODE_MPEG) $(AKODE_XIPH) CLEANFILES=akodearts.h akodearts.cc akodearts.mcopclass akodearts.mcoptype --- branches/KDE/3.5/kdemultimedia/configure.in.in #482638:482639 @@ -345,6 +345,16 @@ AC_SUBST(akode_includes) AC_SUBST(akode_libs) + + + KDE_CHECK_LIB(akode_mpeg_decoder,mpeg_decoder, have_akode_mpeg=yes) + KDE_CHECK_LIB(akode_mpc_decoder,mpc_decoder, have_akode_mpc=yes) + KDE_CHECK_LIB(akode_xiph_decoder,xiph_decoder, have_akode_xiph=yes) + + AM_CONDITIONAL(include_akode_mpeg, test x$have_akode_mpeg = xyes) + AM_CONDITIONAL(include_akode_mpc, test x$have_akode_mpc = xyes) + AM_CONDITIONAL(include_akode_xiph, test x$have_akode_xiph = xyes) + ])
Using this patch ./configure --without-akode fails with: checking if mpeglib_artsplug should be compiled... no configure: error: conditional "include_akode_mpeg" was never defined. Usually this means the macro was only invoked conditionally. Not much of an automake/autoconf guru, so I'm not sure what to do about it.
Found it, you need to set have_akode_* to no before doing the AM_CONDITIONAL checks. And, a small nitpick, wouldn't be better to put the AM_CONDITIONAL's in akode_artsplugin/configure.in.in instead of the top-level configure.in.in?
I just now realized this fix made it into the final 3.5.0 tarballs, however I'm still seeing failure during configure (comment #10) (when akode is not installed), fix in comment #11
Created attachment 14008 [details] move conditionals to akode_artsplugin/configure.in.in
*** This bug has been marked as a duplicate of 134355 ***