[Pkg-mono-devel] Nemerle

[rzyjontko]

Eduard Bloch wrote:
>
> Correct me if I am wrong. Miguel has a different opinion but I guess he
> never tried to create distributable _and_ stable packages from the
> stuff.

I heard something about Global Assembly Cache - maybe this is going to
be a panacea?  Since then, evereybody will have to instruct their
users to set MONO_PATH...

> Not really. The few things we have declared as de-facto policy are:
>=20
>  - depend on cli-virtual-machine to get the interpreter (called via
>    /usr/bin/cli which itself is a symlink to the best VM, configured by
>    update-alternatives)
>  - depend on mono-assemblies-arch if you use System.Drawing (this is a
>    provisoric solution)

When I first looked at how packages are divided, I thought: "so
many?", but now I see it really works - great job.

Will this do:

  Depends: mono-jit (>> 0.28) | cli-virtual-machine

or I should explicitly depend on mono-assemblies-base?
Is there anyone involved in packaging dotGnu?

>  - depend on "mono-mcs | c-sharp-compiler" to get the compiler.=20
>    There is, however, no c-sharp-compiler alternative yet.=20

We don't need C# compiler - Nemerle generates IL binaries, but I have
a question.  Do you bootstrap C# compiler in build target of
debian/rules or just leave it empty?

> Further, please provide a shell wrapper for your .exe file. I wrote a
> binary wrapper which will be in the next mono package and call
> /usr/bin/foo.exe if you make a symlink from the wrapper to /usr/bin/foo
> and call it.

This sounds unreasonable to me.  My IL binaries are run by binfmt_misc
kernel support.  So I thought it would be best to install the binary
(Nemerle compiler is called ncc) in /usr/bin/ncc, and it works.

Please correct me if I'm wrong, but I thought that this is the
preferred way.

> 9.9 Environment variables

My linitan complains about a non-elf, and non-script binary in
/usr/bin, but it was calibrated for version 3.5.10 of policy, and I
haven't found this constraint in 3.6.

Maybe we could summarize all policy violations, and put them all
together to somehow resolve these problems, so that mono could one day
be placed in main.  I suppose I'm also not the only one asking the
same questions.  Maybe it would be best to write a FAQ on packaging
..NET binaries for Debian?

> and we cannot fix it right now. Maybe with the MONO_PATh workaround
> using wrappers for every application, but it really sucks, since people
> will complain that they cannot run their self-compiled mono application=
s
> or by calling them as .exe.

There is a problem only in the situation when user creates an .exe
file linked against a .dll that could not be found by mono (either by
looking to $prefix/lib, or to MONO_PATH - which is a _bad_ hack).  Or
maybe I miss something?


I have one more question.  What about AOT compilation?  It can speed
up many applications (expecially small ones - which run short, but are
loaded long).  Mono creates an .so file for each binary blessed with
mono --aot.  Should every admin run it himself for each binary he
installs on the system or maybe it could be done for him?


PS
I appreciate you forwarded a reply to me, but you could save your
effort.  I am already subscribed to pkg-mono-devel.

----                                ----
rzyjontko              <rzyj@plusnet.pl>
http://www.student.ii.uni.wroc.pl/~rzyj/
----                                ----