Mono and Gentoo: integration needs more work

I’ve already written quite a bit about the fact that I’m mostly a Mono enthusiast and that I think there is work to be done to integrate Mono-based builds into autotools but I haven’t spent enough words about the integration of Mono in Gentoo as a distribution.

Indeed, the Mono team right now seem to be uniquely implemented by Peter Alfredsen (loki_val), which is of course a sub-optimal situation, since nothing should really end up being done by a single person in theory; in practice that’s more than common in Gentoo and that is one of our worst problems. And it’s not just a matter of not having the time to deal with everything, but also that you cannot brainstorm to separate the bad ideas from the good ones, and to polish them so that they can be used by more than a few people.

In paticular, there are quite a few things in the way Gentoo handles Mono that I’d love to see improved, but that I doubt would be considered unless me and someone else would join the team to discuss about them. Now, some things are definitely subjective – for instance I don’t like having upstream packages split in multiple ebuilds, especially now that we got USE-based dependencies, while it seems to be something that Peter loves to do – but others are definitely areas that need some work.

The first problem relates to where do we install Mono files: for some reason, in Gentoo we’re currently installing the Mono libraries under /usr/lib64, for AMD64 multilib systems; this is probably due to the fact that usually they also install 64-bit libraries and thus their libdir is supposed to be suffixed with 64. Unfortunately this is against what upstream uses, since Novell uses /usr/lib for it all — indeed, all the .NET libraries, the .dll and .exe files, are arch-independent, or actually platform-independent, for the most part (see this post for more details about how is it possible for .NET libraries to be arch-dependent). We’re stuck at patching lots of libraries, just like Fedora, because of that path change.

Another problems appears when you factor in the problem of ABI and .NET libraries: while Ruby, Perl and Python don’t really have ABI (at least between programs and native libraries), and Java have ABI but no ABI-definition (thus requiring a lot of manual work for the Java team), .NET policies come very near to ELF files and versioning, for which we have revdep-rebuild already. Unfortunately we have no similar tool for .NET (and it wouldn’t always work fine, given that undefined symbols in .NET are not fatal, and can easily be handled — for instance the software I’m developing only uses Outlook if it can load all its libraries).

Also, that I know of at least, there is no script to verify the properness of the runtime dependencies of Mono software, which is quite a bit of a problem when you end up packaging it yourself. I’m pretty sure somewhere there is a tool to check dependencies akin to the Dependency Walker but I really don’t know about it (if somebody has a name, that would probably be appreciated!).

All in all, there aren’t really big problems with Mono in Gentoo; they really appear no problems at all when you consider what we have yet to fix with Ruby but they still can be a bit of a bother. And they need more people for them to be fixed.

4 thoughts on “Mono and Gentoo: integration needs more work

  1. I’ve always thought that revdep-rebuild (and really, a lot of things in Gentoo) are too centered around C/C++. You get people recommending that you emerge -e world after major toolchain upgrades, and rebuild all non-C packages unnecessarily. (Heck, as long as I’m complaining about that, Gentoo is too tied to GCC – there’s not a clean way to drop in another compiler.)It seems like it should be possible to write a more generic revdep-rebuild, that has helper programs for types of compiled binaries, and uses those to figure out what to rebuild. Could be a SoC project next year, maybe.

    Like

  2. Don’t forget the mono use flag in order to avoid forcing down the throat mono for those who do not want it.

    Like

  3. Yeah, we install in get_libdir. /usr/lib is just an alias for get_libdir anyway, and in the cases where we have no /usr/lib symlink, it won’t break stuff. We’re following Fedora’s lead on this one. It makes sense, we don’t have half-broken /var/db/pkg entries, and we can actually do equery belongs /usr/$LIBDIR/mono/gac/$file and expect that answer to be correct. Also, there are plans in the pipeline to get AOT compilation going and that will require multilib strictness anyway. Also, if we didn’t do it this way, we would just have to do it the other way around, since a good amount of our packages are multilib-aware.I’m working on a tool to check dependencies for packages, it’s in a kind-of-working state right now, but SO SLOW with packages like banshee — around 20 Seconds on a quad-core with caches hot. Also, it doesn’t account for moduleref dependencies yet, since that’s more tricky, with .config files and all.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s