[Mono-dev] Mono support on Fedora, Ubuntu, Solaris, etc.

[Jonathan Pryor]

On Mon, 2008-09-15 at 22:16 +0100, Paul wrote:
> For Fedora/RedHat users, the rule for 64 bit users is that code goes
> in /usr/lib64 rather than /usr/lib. Mono has quite a few packages which
> proports to move code to the correct libdir, but has things hardcoded as
> $(prefix)/lib rather than $(libdir) within config (and even source)
> files.
> 
> To Fedora/RedHat users, this is a 100% no-no.

Where should IL be placed?  Platform-independent IL, at that (e.g.
monodoc.dll, System.Core.dll, etc.)?  openSUSE places this
under /usr/lib, even on 64-bit platforms (which admittedly is rather
odd).  What does Fedora suggest?

(It's not as if this is unique to Mono, either, as Java, Perl, Python,
and others will all have lots of platform-independent code...)

I tried looking at Fedora's wiki, but it's no help -- what directory is
%{buildroot}%{gemdir} (as used in Ruby) or %{_javadir} (Java)?  I have
no idea.

> Another no-no is the packaging of prebuilt libraries. For example, why
> does MD come with mono-cecil prebuilt when there is no good reason for
> not using the version supplied by mono itself?

There is a good reason.  A very good reason.  It makes the MD
development independent of the mono development.

More specifically, Mono.Cecil (and *lots* of other libraries) has NO
STABLE ABI.  Meaning Mono.Cecil could change in a completely
incompatible way *tomorrow*, theoretically.  This is intentional, as
Mono.Cecil is still under development, and bug fixes and optimizations
may require incompatible changes to the API/ABI, among other things.

In short, it's entirely possible for someone to make a change to
Mono.Cecil in mcs and inadvertently break MD.  This is BAD.

Gnome's libegg, should you remember it, was in the same boat: no
guaranteed stable ABI.

So we have three choices here:

1. Declare Mono.Cecil as ABI-stable.  (This would effect *every*
possibly-shared assembly, such as Mono.Fuse, NDesk.Options, Mono.Rocks,
etc., etc.  And as maintainer of at least two of those, I flat out
*refuse* to declare them ABI stable at this point in time.)

I'm not the Mono.Cecil maintainer, but I'm quite sure this isn't an
option.

2. Bundle the binary Mono.Cecil.dll, and build against that.  This is
what MD is currently doing, in accordance with:

http://www.mono-project.com/Guidelines:Application_Deployment#Libraries_with_Unstable_APIs

3. Bundle Mono.Cecil's source with MD.  I fail to see how this is an
effective change from (2), except it increases compile time and disk
space (source >> binary).

So, short of a "don't use any unstable assemblies" (to which I respond
"you're on crack!"), what do you propose as the alternative here?  How
*should* apps use unstable source/libraries?

What I really find fascinating is:

http://fedoraproject.org/wiki/Packaging/Mono

Where it says that using unstable libraries is "extremely poor
practice," but doesn't actually deign to provide us with an alternative
(aside from the implicit "don't use unstable libraries").

Tough.

Until such time as humanity is able to design software *correctly* the
*first* time, there WILL be unstable libraries.  Attempting to ignore
their presence is a JOKE, and not a particularly good one.

 - Jon