Description of problem: Mono installs stuff into $prefix/lib when it probably should install into %datadir instead. This complicates matters since e.g. avahi-sharp happily installs into %libdir and this ends up on /usr/lib64 which is wrong (will file separate bug) - note that dbus-sharp does "the right thing" and installs into %prefix/lib. Version-Release number of selected component (if applicable): Rawhide
For the record, the separate bug is bug 185692
I'm not sure diverging from the upstreams packages in such an extreme way is very good. It will force use to patch every mono-using package, won't it? Anyway, this is something that very much should be discussed with upstream.
Note: All our other packages are either installing into prefix/lib by default or (a few of them) patched to change from libdir to prefix/lib, as this is how the upstream packages are done
Yea, agree that this should be discussed with upstream as it would be a catastrophe diverging for no good reason. Maybe mono ought to include a pkgconfig variable so upstream mono-using packages could use this. Btw, our avahi-sharp package is going to be patched locally to adhere to this scheme (bug 185692). Someone should tell avahi upstream about it. I suppose you can close this as UPSTREAM then.
The Packaging Committee has discussed which hierarchy assemblies belong in and decided on %{_libdir}. So mono should be placed in %{_libdir} rather than %{_datadir} or its present %{_prefix}/lib location. The discussions around this were manifold but basically boiled down to these few points: 1) If mono packages are arch specific they should go into %{_libdir}. 2) If they are noarch, they belong in %{_datadir}. In neither case is %{_prefix}/lib the correct placement. Mono packages may not contain any arch specific code but because a system administrator may want to AOT compile them _and_ because the mono runtime cannot find AOT binaries unless they are in the same directory as the assemblies, we need to consider all packages which use the mono runtime as arch specific.
Created attachment 132791 [details] Patch to place mono in %{_liibdir} rather that %{_prefix}/lib Here's a first cut at placing mono into %{_libdir}/mono instead of /usr/lib/mono. I've modified configure.in, a few Makefile.am's, the pkgconfig files, and some Makefile fragments that may or may not be relevant (I'm not sure if the mono build is completely autotooled or if some portion is writing and pulling in these Makefile fragments instead.) Along with the spec file patch I'll submit next, this places all mono files into %{_libdir} and grepping the files doesn't show any occurrences of /usr/lib or prefix + lib. I haven't installed and tested yet. I need to work on patches for the other .net packages that use the GAC in order to get to that stage.
Created attachment 132793 [details] spec file patch to place mono in libdir This patch to the spec file applies the libdir patch, runs autoreconf to apply the changes to configure.in and Makefile.am, updates %monodir to expect files to end up in %{_libdir}, and also owns the mono/compat-* directories.
Okay. Next step is to determine what other packages need to have fixes applied in order to use the new location. anything that's installing into the gac will need changes. On my system this is: avahi-sharp dbus-sharp evolution-sharp gecko-sharp2 gmime-sharp gsf-sharp gtk-sharp gtk-sharp2 muine Do you know of some way I can determine if I'm missing anything in this list? Also, will I need to do anything special to programs which are not in the gac, but depend on libraries installed within it? IIUC, the pkgconfig files should tell the programs how to locate the libraries at compile time. Does this mean they need a recompile but should work after that?
Where is the mono-libdir.patch file? Can you attach it to this bug please?
I'm not sure its a good idea to move around all the mono packages and their dependencies so late in the cycle. Especially since it means we'll be different than upstream which could easily cause new bugs to pop up.
#10, you're probably right. I just get annoyed that packages have to fiddled with so much because upstream have messed up with where things have to go
I tested the patch above. I still get conflicts when installing both the 32bit and the 64bit mono-core package. The problem is that the binary wrappers such as /usr/bin/gacutil now differ (lib vs lib64). I'm not sure what the best way to solve this is. Depending on what you want to do you really want different exes. For instance, if you're building a 32bit mono dll on 64bit you want to use the 32bit gacutil when installing, otherwise it'll be installed in the wrong directory (i think, because the mono dir is compiled into gacutils).
From the digging around I've done and looking at the build structure and associated files, it seems that /usr/lib is very deliberate on the part of Ximian (as was) and now Novell. There are two solutions to this problem that I can see. 1. We create a new macro (call it _monodir) which always puts things into /usr/lib irrespective of architecture 2. We fix mono ourselves so that it becomes architecture agnostic. The problem with (2) is that it's not easy - mono relies on things being in /usr/lib and /usr/lib/pkgconfig. It can be done, but there is that much hacking around on both mono and on packages associated with mono that it becomes hard to justify. I'm not saying we shouldn't fix it - I'm just asking on the time justification. (1) is what is currently happening except that the macro would be similar to %{_bindir} and be built in to rpmbuild (or whatever it is that defines these macros) I'm personally not happy with (1), but then I'm not happy with mono being fundamentally broken and upstream not being that willing to do anything much about it. However, it does seem to be an answer - probably not the best one though.
Ugh. Forgot about %{_bindir}. If we don't want to have the 32-bit programs on x86_64, then we could subpackage around the issue in the spec file. If we do want the 32-bit versions then we'd probably have to add a bittedness suffix: gacutil64 etc. From a packaging perspective we invoke gacutil at build time, not install time so there's no need to have both 32bit and 64bit versions of gacutil installed. Additionally, gacutil has a -root option that can specify an alternate path to the gac: gacutil -i -root /usr/lib So the end-user can install into /usr/lib if they have that need. Do you know if the library path is hardcoded into any of the other programs?
It seems like the library path is only hardcoded into the mono jit itself, not in any of the dlls. However there are lots of places in that code that currently hardcode or assume "lib", not "lib64" (see assembly.c), so the attached patch is not good enough, and this change will be pretty major. So, whatever version /usr/bin/mono is, that will decide what mono dir gacutil uses by default. We certainly don't want to call mono "mono32" on x86 machines, nor do we want to add prefixes for every mono using app that we ship. Especially when they are basically noarch all of them. I think the best approach is something like using /usr/lib, and then handling mono .exe and .dll multiarch conflicts better in rpm (similar to how we do elf ones). Then solve the ahead-of-time problem in some other way. I'll continue looking at this tomorrow.
Also, i ran cmp on two .dll files built on 32bit and 64bit. They differed only in about 15 bytes, which i assume was timestamps or something. Maybe we can make them identical so that we don't get conflicts.
Re: Comment#15(In reply to comment #15) > It seems like the library path is only hardcoded into the mono jit itself, not > in any of the dlls. However there are lots of places in that code that currently > hardcode or assume "lib", not "lib64" (see assembly.c), so the attached patch is > not good enough, and this change will be pretty major. I found the following relevant functions by searching for "lib" in assembly.c. Let me know if I've missed anything:: mono_assembly_setrootdir(): Sets default_path[0] to the pathname passed in as an argument. mono_set_dirs(): If this function is given a directory path it sets the assembly_dir to that directory using mono_assembly_setrootdir(), otherwise it sets the path to MONO_ASSEMBLIES. MONO_ASSEMBLIES is set in mono/metadata/Makefile.am to $(assembliesdir) which is set to $(libdir) with my patch. fallback(): Calls mono_set_dirs() with no directories, so if we use fallback(), assembliesdir will be $(libdir). set_dirs(): Checks for the existence of $prefix/lib/mono/1.0. If that is not found invoke fallback(). mono_set_rootdir(): References "lib" within a WIN32-only section, otherwise invokes set_dirs(). mono_assembly_load_with_partial_name(), mono_assembly_load_publisher_policy(), mono_assembly_load_from_gac(): If the environment variable MONO_GAC_PREFIX is set, attempt to load the assembly from a user defined gac in the MONO_GAC_PREFIX/lib/mono/gac/ASSEMBLYNAME. If the assembly isn't found in the user defined GACs then fallback to the gac defined in mono_assembly_setrootdir(). If that's everything and only the mono runtime needs to know where mono/gac is located then the patch should be sufficient. I did a grep for \"lib\" in the mono/ subdirectory which didn't turn up anything else relevant. The mcs subdirectory also had "lib" in it but someone would have to check whether they were actually referencing the path ("/usr/lib") or a prefix ("libbanshee.so"). > So, whatever version > /usr/bin/mono is, that will decide what mono dir gacutil uses by default. > > We certainly don't want to call mono "mono32" on x86 machines, nor do we want to > add prefixes for every mono using app that we ship. Especially when they are > basically noarch all of them. > I agree this is something we want to avoid. > I think the best approach is something like using /usr/lib, and then handling > mono .exe and .dll multiarch conflicts better in rpm (similar to how we do elf > ones). Then solve the ahead-of-time problem in some other way. I'll continue > looking at this tomorrow. > Solving the AOT problem would work. If mono can generate AOTs in a different, arch specific directory structure and find them there when it needs, then the assemblies should be okay in /usr/lib or datadir. There are two caveats: 1) Some subset of packagers would then want assemblies in %{_datadir} since they would then be arch independent (so the packaging committee would have to hash out if that was a worthwhile change and then we'd sit in another bug trying to figure out how to implement it :-) and 2) My understanding is that getting mono to find AOTs is actually a much more intrusive change than relocating the mono runtime to %{_libdir}
re 1) I'm not sure we can split the GAC up in both libdir and datadir. I think it has to be in one directory. re 2) That is possible, but switching to libdir causes other problems (binary wrapper conflicts) that i'm not sure have a good solution. An interesting question is why the 32bit mono-core and mono-devel packages are in the 64bit yum repository. That is the main cause of immediate problems.
#18 Point 1 : You can't. I've tried that and it ends up a complete mess. The whole purpose of keeping to one directory is to ensure the same source base can be used and that gacutil always knows where to look without having to mess around with the platform (for example, Win32 would use C:/Windows/System32, OS X would use something insane and we're in /usr/lib/mono/gacutil) Point 2 : I quite agree. Having the .exe's in /lib with a wrapper in %_bindir is dumb, especially with naming and access conflicts. "An interesting question is why the 32bit mono-core and mono-devel packages are in the 64bit yum repository. That is the main cause of immediate problems." /me looks sheepish as I seem to be the biggest contributor of .NET apps to FE! There are two problems here. The first is that those reviewing .NET apps have no guidance on the wiki as how to identify a 32 bit only dll. Second to that is that rpmlint really isn't that well suited to testing .NET apps. It's great for standard applications, but doesn't recognise or plain gets wrong pieces of the .NET infrastructure. Possibly a solution would be for the buildsys to do what it does with the likes of OOo in core and call the package i386 for x86_64/ia64 architecture if it detects it is a 32 bit only dll once built. Not sure what the best way to do that would be. I suppose if it builds the i386 rpm first, then the x86_64 and compares the filesize, if they're the same, call it i386. Failing that have the packager check (create a new rpmlint called rpmlint.net or give instructions on the wiki) and include a flag in the spec - something like Netver : 32 | 0 [0 = has both 32 and 64] which instructs the buildsys that the rpm for the 64 bit repos has to also be called .i386 As for the packages already in FE, I'm not sure there is anything I can do other than excludearch them - which I'm loathed to do as they don't upset anything (currently) and also it would be wrong as they do build under 64 bit, just not have the correct arch name.
So, it seems the reason we have the 32bit mono in the 64bit repository is because there is a mono-devel package, and for all *-devel packages we add the 32bit version to the 64bit distro. This pulls in mono-core, which conflicts with 64bit mono-core because the .dll and .exe files differ (in very minor ways).
Hmm. Why would having the -devel packages add the 32 bit version to the 64 bit distro? I'm actually wondering if the difference in the dlls and exe's are down to the likes of struct padding rather than anything else (see http://www-128.ibm.com/developerworks/linux/library/l-port64.html)
the -devel matching is part of the distro compose magic. The difference in the dlls seems to be only a timestamp and a different strong name. The padding and sizes are identical. Also, i'm thinking the ahead of time compilation is really not a problem. There is no reason to want aot compiled versions for both 32bit and 64bit, because once you have the 64bit mono installed you can't really start the 32bit jit, because /usr/bin/mono will always be the 64bit one.
(In reply to comment #18) > re 1) I'm not sure we can split the GAC up in both libdir and datadir. I think > it has to be in one directory. > This is the change I'm talking about. We have to make it so the GAC can place AOTs into %{_libdir} even when the assemblies are in /usr/lib. Like I say, this is a more intrusive change than moving all of the GAC to %{_libdir}. > re 2) That is possible, but switching to libdir causes other problems (binary > wrapper conflicts) that i'm not sure have a good solution. > The binary wrapper problem is trivial to fix. You need to have the binary wrappers in a separate subpackage from the assemblies.
Created attachment 133851 [details] spec files patch that also accounts for bin wrappers Here's a preliminary patch to the spec file that breaks apart the assemblies and the bindir programs. This way mono-core is a multiarch capable package. This is proof of concept but not quite up to Fedora Guidelines. All packages should depend on the %{name} package. So the names of the mono and mono-core packages should be switched. I'll do that cosmetic touch up after I finish commuting to work. Go ahead and comment on whether this works for your testing, though.
I had another idea for an easy multilib fix. We split mono-core into mono-lib and mono-core, with mono-lib only containing libmono and the stuff needed for embedding mono. Then we split up mono-devel to mono-devel (containing libmono header, pc file and libmono.so) and mono-devtools containing the rest. This will pull in mono-devel and mono-lib as both 32bit and 64bit libs in the distro. It will be without conflicts, and it will properly allow both 32bit and 64bit apps to embed mono. The conflicting 32bit files will not be pulled into the 64bit distro, and both libraries will share the same dlls etc. I just think duplicating all the arch independent .dlls is wrong. And I don't buy the AOT argument. There is just no way to use both 32bit and 64bit AOT .so files at the same time, since we only have one version of the jit. I also think splitting out the bin wrappers is a very strange and unexpected packaging.
(In reply to comment #25) > I had another idea for an easy multilib fix. > We split mono-core into mono-lib and mono-core, with mono-lib only containing > libmono and the stuff needed for embedding mono. Then we split up mono-devel to > mono-devel (containing libmono header, pc file and libmono.so) and mono-devtools > containing the rest. > That should work to fix Bug #199790 > I just think duplicating all the arch independent .dlls is wrong. I do to. So the true solution is assemblies belong in %{_datadir}. If the package has no glue libraries, these packages can be noarch and thus there's no duplication of arch independent assemblies on i386, x86_64, and ppc. > And I don't > buy the AOT argument. There is just no way to use both 32bit and 64bit AOT .so > files at the same time, since we only have one version of the jit. Where were you when we had to discuss this on fedora-packaging? :-) Your input would have been greatly appreciated. What happens if you have /usr/lib network mounted? In multiarch, I should be able to have /usr/lib shared between i386 and x86_64 with a separate /usr/bin for each arch. If AOTs are in /usr/lib, /usr/bin/mono is going to be pretty upset with me. > I also think > splitting out the bin wrappers is a very strange and unexpected packaging. > It's the standard way to do such things. Splitting out the libs is the same thing in reverse. Look at db4, poppler, etc. We can go with a subpackaging only approach to fix 199790 for now. This keeps us from having to make a big change this close to FC6 which is a big relief for some (Extras seems to want the changes made sooner so they can fix their packages.) For the FC7 devel cycle we either need to move mono to %{_libdir} or you need to bring your AOT ideas to the packaging committee to see what falls out. Judging from the discussion last time, the leading proposal will be: 1) packages with assemblies and no shared objects are noarch and go in %{_datadir} 2) packages with assemblies and shared objects (glue libraries) go in %{_libdir} and are arch specific 3) mono needs to be able to find AOTs in %{_libdir} even when the assemblies are in %{_datadir}. Our present guidelines with everything in %{_libdir} are a compromise between the ideal and the practical. Making #3 work looks like something that is best done with upstream cooperation (and preferably by upstream :-). If we just want to move things into %{_libdir} we can do that with the subpackage approach (which you're going to do anyway) and my patch. Plus patching (or unpatching in some cases) the build scripts to the other mono packages.
>> I also think >> splitting out the bin wrappers is a very strange and unexpected packaging. > It's the standard way to do such things. Splitting out the libs is the same > thing in reverse. Look at db4, poppler, etc. Maybe it makes some sense for mono, which has a .so file. But take a normal mono app/library. It will have both dlls (or exes) and binary wrappers. Would you also split tomboy into two packages? >2) packages with assemblies and shared objects (glue libraries) go in > {_libdir} and are arch specific Ideally this shouldn't be needed. Such shared glue libraries are already in lib/lib64 (take a look at for instance gtk-sharp2 on x86-64) and are loaded correctly. If we could make either the dlls be identical (fix timestamp and strong name differences) or make rpm ignore the dlls conflicts things would just work. Anyway, for FC6 i'll just do the mono-lib split.
(In reply to comment #27) > Maybe it makes some sense for mono, which has a .so file. But take a normal mono > app/library. It will have both dlls (or exes) and binary wrappers. Would you > also split tomboy into two packages? > Libraries don't have binary wrappers, only apps. Tomboy doesn't need a split -- there's no devel package. If you have a package that includes both programs and libraries then yes, it needs to be split. This is nothing new -- it's the same as libraries and applications written in C. We've been filing bugs and making those splits for a long time now. elfutils, bind, bzip2, etc. > >2) packages with assemblies and shared objects (glue libraries) go in > > {_libdir} and are arch specific > > Ideally this shouldn't be needed. Such shared glue libraries are already in > lib/lib64 (take a look at for instance gtk-sharp2 on x86-64) and are loaded > correctly. Sounds reasonable. Assemblies into %{_datadir} and the shared objects into %{_libdir}. The package still has to be arch specific. > If we could make either the dlls be identical (fix timestamp and > strong name differences) or make rpm ignore the dlls conflicts things would just > work. > It just works in the sense that the program runs. It doesn't work in the sense that using %%{_prefix}/lib conflicts with the FHS + multilib. Either the assemblies have to be treated as arch specific (because of the AOTs) and go in %{_libdir} or the assemblies can be treated as arch independent (with AOTs being read/written to a %{_libdir} hierarchy) and then they go to %{_datadir}. > Anyway, for FC6 i'll just do the mono-lib split. > That sounds like the best plan for this release.
Ok. So, what we have is: Modify mono so that assemblies are loaded from /usr/share/mono/. Modify mono to load/write AOT .so files for dlls in the gac in the %_libdir/mono/gac tree. Make sure 32bit and 64bit compiled dlls from same source are identical. Pure mono lib packages are noarch Mono lib packages with glue libraries are arch, and put the .so files in %{_libdir}. Pure mono apps put stuff in %datadir/appname/ and are noarch. Mono apps that have a glue lib put stuff in %libdir/appname and are arch dep. These apps will not be multilib safe as the binary wrapper will conflict. Seems like it could work. Its quite some work though.
Yes, that looks right. And you have a gift for understatement :-) If you think it's worthwhile to attempt that level of change we should present the plan to the packaging committee so we can get more eyes on it.
With this new release in rawhide (11th Aug 2006), what impact does it have on packaging? Do I need to rebuild all of my mono stuff in FE?
Toshio: I don't really think its worthwile. Its a load of work, and its mainly for estetical reasons. However, maybe we can get some buy-in from upstream for going this way. Then it seems like a better idea. Paul: The only change you might need to do with the rawhide change is to change BuildRequire: mono-devel (if you have any) to BuildRequire: mono-devtools. (Unless the package actually embedds mono.)
When the packaging committee met, they thought it was too much work to implement a shift to %{_datadir} on our own as well. That's why the guidelines were written to place things in %{_libdir} instead. So far it seems that the patch I provided accounts for all the references to "lib" within the mono runtime. The mcs/ hierarchy has two pieces of suspect code: mcs/tools/gacutil/driver.cs: EnsureLib() When gacutil is given a dircetory for a user-defined gac on the commandline, this function is used to confirm that it is a valid directory. The check asks if the directory is "lib" and if not, appends "lib" to the end. It is not necessary to change this as user defined directories within the user's home dir are going to be "lib". If we want we can patch this to allow either "lib" or "lib64", though. mcs/class/Microsoft.Build.Utilities/Mono.XBuild.Utilities/MonoLocationHelper.cs: MonoLocationHelper(): This one needs some analysis. The code takes the assembly dir and strips off levels until it gets to the $prefix. Then it re-appends "lib" to make a "libdir" which can be accessed from the MonoLocationHelper.GetLibDir() method. This method is never invoked in the mono source code. If we wanted to retrieve the proper libdir for the platform it seems like the code should save the libdir when it is stripping off directory levels instead of reappending "lib". Since no other code uses this, I can't verify what the reason is for using such a strange algorithm in the first place is, though. So between the first patch, patching these two mcs/* files, and splitting %{_bindir} stuff from %{_libdir} (which you're already doing conceptually to fix the multilib problems) mono should place itself into %{_libdir} fine. If you think upstream may buy into helping to do the work to switch to %{_datadir} then we need to confirm that upstream is willing to make this change and put the proposal to the packaging committee. If not, the %{_libdir} change seems just about complete to me (unless you can find other problems with it.) If you have a third alternative, feel free to bring it up and propose it to the Packaging Committee.
Mono 1.16.1-2 has dlls and exes in %libdir, and the binary wrappers are modified so that they are identical on all arches by calling the executable "monodir" to get the current mono directory. Since monodir is an elf binary the rpm file coloring will handle that the same way as the "mono" binary, thus it will always point to the currently active arch. I've started to convert all the mono packages to put dlls in libdir.
Can you upload the srpms (x86_64 and i386) so I can get going on my packages as well? Can I also take it that the likes of pkgconfig is correctly picking up from usr/lib64/pkgconfig?
Can you upload the rpms (x86_64 and i386) so I can get going on my packages as well? Can I also take it that the likes of pkgconfig is correctly picking up from usr/lib64/pkgconfig?
All the packages are in rawhide now.
Excellent. They seem nice and stable. Any chance of pushing them into core? Rebuild time for my packages I think once that's done (the changes [-devel in gtk-sharp2 and gnome-sharp] break quite a lot of what I have in extras)
What do you mean by "core", its already in fedora core? Did you mean FC5? Thats not likely at this point.
Sorry, yes. I class core as being the stable release rather than rawhide. Apologies. Problem is though that FC5 is now broken for mono without the devel packages. Okay, I realise that we're close to FC6 hitting pay dirt, but having FC5 broken just ain't cricket.
How can FC5 be broken? Its a stable distribution, and as such it hasn't changed at all wrt to these changes.
In FC5, the monohack is still required due to still being on the -1 release, the -2 release in rawhide fixed that and also altered how the core mono package was released.
I still don't understand what you're talking about. What is the -1 release? FC5 has "mono-1.1.13.7-1.fc5.1", which has everything in /usr/lib/mono, and rawhide/FC6 has "mono-1.1.16.1-2.fc6" which uses %_libdir/mono.
Re: Comment #34 Thanks Alex! Re: Paul Moving the mono library directory is a big change affecting nearly all the mono-using packages. It's not really a change that's suitable for a stable release. So you're going to have to continue to do things differently on FC5. You'll either have to maintain a different spec file there or use conditionals to detect the version of fedora you're building on and use the correct directories for that release.
Looks like something is still wrong. gtksourceview-sharp isn't building for x86_64 in rawhide... Job failed on arch x86_64 Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/14532-gtksourceview-sharp-2.0-16.fc6/ ------------------------------------------------- + rm -f /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/share/gtksourceview-1.0/language-specs/vbnet.lang + /usr/lib/rpm/find-debuginfo.sh /builddir/build/BUILD/gtksourceview-sharp-2.0-0.10 0 blocks find: /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib/debug: No such file or directory + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump + /usr/lib/rpm/brp-python-bytecompile Processing files: gtksourceview-sharp-2.0-16.fc6 error: File not found: /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/mono/gac/gtksourceview-sharp error: File not found: /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/mono/gtksourceview-sharp-2.0 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.31142 + umask 022 + cd /builddir/build/BUILD + cd gtksourceview-sharp-2.0-0.10 + DOCDIR=/var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/share/doc/gtksourceview-sharp-2.0 + export DOCDIR + rm -rf /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/share/doc/gtksourceview-sharp-2.0 + /bin/mkdir -p /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/share/doc/gtksourceview-sharp-2.0 + cp -pr AUTHORS COPYING INSTALL NEWS README /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/share/doc/gtksourceview-sharp-2.0 + exit 0 Processing files: gtksourceview-sharp-devel-2.0-16.fc6 error: File not found: /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/pkgconfig/gtksourceview-sharp-2.0.pc Processing files: gtksourceview-sharp-debuginfo-2.0-16.fc6 RPM build errors: File not found: /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/mono/gac/gtksourceview-sharp File not found: /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/mono/gtksourceview-sharp-2.0 File not found: /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib64/pkgconfig/gtksourceview-sharp-2.0.pc I've removed the monodir hack and get the above
This is a problem with gtksourceview-sharp, not with the new mono packaging. Here's the relevant line from your build.log: /usr/bin/gacutil /i gtksourceview-sharp.dll /f /package gtksourceview-sharp-2.0 /root /var/tmp/gtksourceview-sharp-2.0-16.fc6-root-mockbuild/usr/lib gtksourceview-sharp is using the -root option to specify where it wants to be installed. In this case, it is erroneously saying /usr/lib. If gtksourceview-sharp didn't supply a /root option or used %{_libdir} instead of $prefix/lib then it would do the right thing.
This is probably why a lot of the fun and games started in the first place, the packages makefiles and configuration files have the problems and not us. Oh well, time to hack around...
A lot of makefiles let you specify GACUTIL_FLAGS though, which lets you easily fix things like this.
There are other reasons than AOT to keep 32-bit and 64-bit .NET binaries separate. According to this: http://www.request-response.com/blog/PermaLink,guid,34966ef8-3142-46b2-84e0-372b5c36ddcc.aspx Microsoft keeps separate copies of their class library (BCL) for 32-bit and 64-bit: This document: http://msdn.microsoft.com/netframework/programming/64bit/default.aspx specifies things which will make a 32-bit .NET binary impossible to use on a 64-bit VM. Any binary which has 'unsafe' code blocks is not portable. I didn't understand whether P/Invoke, which is used a lot by things like gtk-sharp and avahi-sharp, is one of the things which make a binary non-portable. They say that a .NET binary should be "verifiable" if it's to be portable. Microsoft has a utility called PEInvoke.exe which can confirm that. Until we have such a utility, we should assume every DLL to be non-portable and instal it in %libdir.