[Pkg-mono-devel] The Mono Debian Plan [was Re: Mono packaging on Debian.]
Mirco Bauer
meebey@meebey.net
Sat, 19 Feb 2005 13:18:44 +0100
--=-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--