[Pkg-mono-devel] The Mono Debian Plan [was Re: Mono packaging on Debian.]
Sat, 19 Feb 2005 13:18:44 +0100
I talked about this posting with Miguel via IRC, I prefer one short
I will write a quick response here anyhow for the readers of this
mailing list, the result of the discussion with Miguel leads me to a new
plan which you can find here: http://wiki.debian.net/?MonoDebianPlan
(comments are welcome).
On Sun, 2005-02-13 at 00:31 -0500, Miguel de Icaza wrote:
> * 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.
I fully agree here, we tried a few times to get in contact with mono
developer but failed for several reasons.
> * 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=20
> 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.
We plan (see the plan) to package Mono 1.1.x
> * 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.
This is done since Mono 1.1.3, we really appreciate this change.
> * 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.
probably .NET is a registered trademark, dotnet maybe not, though this
naming this be avoided, yes
> 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
it's a directory base name like is /usr/share/java too
> 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
> This means that the code should not be in $prefix/share for
> any reason. The dlls should not be considered shareable across
ok this one is a showstopper, we considered CIL assemblies are in any
> 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=20
> stuff in 'share' you are making the code effectively
this is another big issue, which we must solve, breaking potential and
important features is a no go.
> * 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.
/usr/bin/cli can be used but must not be used, if the program can run on
any runtime without specific runtime parameters (most programs don't
need any) then it can call /usr/bin/cli, if a program depends on the
mono runtime for whatever reason (like special parameters) it can always
call /usr/bin/mono directly.
> Pkg-mono-devel mailing list
Mirco 'meebey' Bauer
-----BEGIN GEEK CODE BLOCK-----
GIT d s-:+ a-- C++ UL++++$ P L++$>+++$ E- W+++$ N o? K- w++>! O---- M-
PE+ Y- PGP++ t 5+ X++ R tv+ b+ DI? D+ G>++ e h! r->++ y?
------END GEEK CODE BLOCK------
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
-----END PGP SIGNATURE-----