[Pkg-mono-devel] Mono packaging on Debian.

[Miguel de Icaza]

Hello, 

    I am mailing you because you seem to be involved in the Mono
packaging for Debian.   I apologize if I have reached you by mistake.

    The other day I was on the #ubuntu channel with a few folks trying
to debug a few problems, and a few things were brought to my attention. 

    I have read the document here:

	http://wiki.debian.net/?MonoConventions

    I do not know how much of this document has been implemented, so my
comments might be incorrect.  Please correct me if I am wrong.

    And wanted to discuss a few things:

* Working together

        There are some important elements from that web page that we
        have integrated into Mono itself rendering some of your local
        changes un-necessary.
        
        I would like to get some feedback directly from you on the kinds
        of things that you are doing, so we can incorporate those into
        Mono proper reducing the per-distribution specific patches.
        
* First

	There is a phenomenon: Mono 1.1.4 is now more stable, more
	reliable and better tested than Mono 1.0.xx ever was.

	Starting with this release (packages will be officially made
	available on Monday) we will recommend users to move to 
	Mono 1.1.4 and abandon the 1.0.xx series, as we consider the
	1.0.xx very buggy in contrast and has several limitations.

* Executables

	We have moved all of the Mono executables from $prefix/bin and
	placed them in $prefix/lib/mono/VERSION, so there are no longer
	.exe files lying in $prefix/bin.

	This should address various of the needs that you have, in
	particular this means that we always have scripts in
	$prefix/bin so there is no need to create new ones.

* FHS

	There are some problems with your assumptions and the way you
	have laid out packages.  The ideal situation is for you guys
	to not make any changes to the locations that Mono is using.

* /usr/share/dotnet

	This is a bad name for a number of reasons.

	First of all `dotnet' is a registered trademark.

	Second, we have worked really hard to make sure that we have two
	stacks: the Mono stack and the .NET stack, and you guys sticking
	a `dotnet' in the name will not help with perception from
	people.

	Third, this is the most important one: although *today* *most*
	of the DLL libraries that we ship are cross-platform, there is
	no guarantee that this will continue.

	Not only it is not a guarantee for Mono, but it is not a
	guarantee for third-party assemblies, these in particular are
	even more prone to include per-OS/per-architecture bytecode
	(Xsharp is one example, but the pattern is now used by various
	projects).

	This means that the code should not be in $prefix/share for
	any reason.  The dlls should not be considered shareable across
	platforms.

	Fourth, it breaks Ahead-of-Time compilation: AOT requires a
	shared object living next to the assembly with native code
	(another reason that `share' wont work).  By putting the 
	stuff in 'share' you are making the code effectively
	non-shareable.

* The use of /usr/bin/cli

	The command line options for `mono' and `mint' are different
	(and even Rotor's clix uses different options), if you are going
	to use a /usr/bin/cli, this should not be a symlink, this should
	be a new shell program that knows how to properly pass command
	line options to all possible environments.

	`Mono' is not like `java' in that the runtime arguments are
	fairly standard.  In Mono there is no effort to do this, and we
	recommend that you do not try to isolate it.

Miguel.