This package seems to be getting built on multiple architectures right now. In fact the software is architecture independent and I believe should be 'noarch'. This means that both ndesk-dbus and ndesk-dbus-glib can be built once and installed on any supported platform, reducing build time and installation media sizes.
Thank you for your bugreport Alp, I value your expertise being upstream for said packages however I'm closing this as NOTABUG. Making the packages noarch would be in contradiction with the Mono packaging guidelines as it would make post packaging AOT problematic. http://fedoraproject.org/wiki/Packaging/Mono -- File Locations Mono packages should install assemblies to %{_libdir} rather than /usr/lib or %{_datadir}. In most cases the preference is for %{_libdir}/PACKAGENAME. We use %{_libdir} because we do not consider mono packages to be noarch. The main reason for this is that mono can ahead-of-time compile its assemblies into ELF shared objects. These AOTs have to exist in the same directory as their DLL/EXE counterparts otherwise mono cannot use them. Even if we, as packagers, choose not to create the AOT files when we build the mono rpms, the system administrator can choose to create them after install. Since there's no way to place the mono assemblies into an arch independent directory and the AOTs into arch dependent directories, the whole thing has to go into an arch dependent tree. --
David, The path where AOT shared objects go is just a hack to make life easier for the developers, and it probably won't change until AOT makes things consistently faster rather than slower. AOT shared objects are conceptually equivalent to cache files, and they will most likely eventually be stored in a cache path, perhaps in /usr/lib, perhaps somewhere more temporary, but only when the feature starts to become useful. Even when AOT support is complete, my understanding is that it won't be suitable for packaging in distributions, because the generated machine code may be very closely tied to the architecture at a much higher granularity than the list of architectures supported by any distribution. These really are cache files, no kidding. The very foundation of the Mono project is to provide portable libraries and applications which don't have to be recompiled on different architectures. AOT is a neat new feature that might speed things up when it's ready, but it has no bearing on any packaging policies, and if AOT ever becomes supported, it will obviously be made to follow filesystem hierarchy guidelines, rather than the other way round. This all makes a bit more sense if you consider what will end up in the RPM for each architecture you support right now -- exactly the same thing, byte for byte. This is pretty much the definition of a noarch package.
Alp, we appreciate your explaining this. But as it stands, the AOTs must be in the same directory as the bytecode (which _would_ theoretically be arch-independent). The package itself must be made arch-specific so that the bytecode libraries and AOTs share the same arch-specific directory when run.
I'll have to admit I do agree with Alp (hence why I originally changed the package to be noarch). I'll leave the bug as closed but I will elevate the packaging problem to the Mono SIG in hopes that we can get the guidelines changed - for now my hands are tied though. The guidelines seem to sabotage one of the fundamental benefits of using Mono and it saddens me especially since it seems we are doing this for an obscure cornercase. We should be about good defaults, the good default here would be to have mono packages be noarch.