[Pkg-mono-devel] The Mono Debian Plan [was Re: Mono packaging on Debian.]

[Mirco Bauer]

--=-cIpI1/81adfA+xZDeUQh
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

I talked about this posting with Miguel via IRC, I prefer one short
interactive discussion.

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:
> Hello,=20
> ...
> * Working together
>=20
>         There are some important elements from that web page that we
>         have integrated into Mono itself rendering some of your local
>         changes un-necessary.
>        =20
>         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.

>        =20
> * First
>=20
> 	There is a phenomenon: Mono 1.1.4 is now more stable, more
> 	reliable and better tested than Mono 1.0.xx ever was.
>=20
> 	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

>=20
> * Executables
>=20
> 	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.
>=20
> 	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.

>=20
> * FHS
>=20
> 	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.
>=20
> * /usr/share/dotnet
>=20
> 	This is a bad name for a number of reasons.
>=20
> 	First of all `dotnet' is a registered trademark.
probably .NET is a registered trademark, dotnet maybe not, though this
naming this be avoided, yes

>=20
> 	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.
it's a directory base name like is /usr/share/java too

>=20
> 	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.
>=20
> 	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).
>=20
> 	This means that the code should not be in $prefix/share for
> 	any reason.  The dlls should not be considered shareable across
> 	platforms.
ok this one is a showstopper, we considered CIL assemblies are in any
case arch-indep.

>=20
> 	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
> 	non-shareable.
this is another big issue, which we must solve, breaking potential and
important features is a no go.

>=20
> * The use of /usr/bin/cli
>=20
> 	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.
>=20
> 	`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.

>=20
> Miguel.
>=20
> _______________________________________________
> Pkg-mono-devel mailing list
> Pkg-mono-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-mono-devel
--=20
Regards,

Mirco 'meebey' Bauer

PGP-Key:
http://keyserver.noreply.org/pks/lookup?op=3Dget&search=3D0xEEF946C8

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GIT d s-:+ a-- C++ UL++++$ P L++$>+++$ E- W+++$ N o? K- w++>! O---- M-
V? PS
PE+ Y- PGP++ t 5+ X++ R tv+ b+ DI? D+ G>++ e h! r->++ y?
------END GEEK CODE BLOCK------

--=-cIpI1/81adfA+xZDeUQh
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)

iQEVAwUAQhcupHEn5avu+UbIAQKzzwf/Ul0tPeA4EW3JWLfNpae9PyBzmudnveim
Ebar0sjsdYQE866b4uDPcgZ+U37joczC2q+E8nc1zwbOkqk7CnCJ31/Sn8xfwLkQ
dE9ZQazSs6fO1msJWfN20HMLw3DP6Qt6oJkQ6Mu+XYBxQJmPabXxp+Adt39GYtEE
B+xesWENo7zmCym4BwQ+lneEdQKF3YEMxKDaIt9PAlfxWsCwxdAoWbiJgtNopTCJ
dRlgz4zW/lI2Ovzp6JrzbQEQC184PRBmeRo+rOlkcXUCYinF7np8Mza3O8t+VbNB
0lkWPtJJjuvd+hcQsFbHQ25qcArqfMwWis7EBdg8YKw1gZzVEEh9Rg==
=0BbK
-----END PGP SIGNATURE-----

--=-cIpI1/81adfA+xZDeUQh--