[mono-packagers] Startup Scripts Inconsistency in Mono 2.0

[Mirco Bauer]

On Sun, 19 Oct 2008 16:47:10 -0400
Jonathan Pryor <jonpryor at vt.edu> wrote:

> On Sun, 2008-10-19 at 17:00 +0200, Mirco Bauer wrote:
> Ignore Mono for the moment.  If I have gcc 3.x and 4.x installed,
> which version should `gcc` refer to?  If I have multiple versions of
> Java installed, which does `java` refer to (by default)?  What about
> for Python?

No need to argue here, I am with you.

> 
> Tools should always default to their most recent versions, full stop.
> Anything else is asking for pain, pain that has been going on for
> years, and pain that we should stop if at all possible.

Yes it should, but it doesn't.

> Agreed, the tools need to be consistent, and (as stated above) they
> should default to the 2.0 profile in all cases.  (And when .NET 4.0
> comes out -- assuming it requires a different profile -- then the
> tools should run under the 4.0 profile, etc., etc., such that the
> tools *always* run under the *current* framework version.)

Yes, then please make this happening!

One thing that needs to be solved too is the compiler. There is no
improvement when an application uses mcs and al at build time making it
mixed 1.0 and 2.0 with Mono 2.0.

Rather we should introduce a compiler default that always points to the
latest runtime version, e.g. csc pointing to gmcs. This way developers
can use the known tools: csc/al/sn/gacutil and always get them for the
latest installed runtime version. That's what I call consistency at
least.

Right now, there is only mcs (1.0), al (2.0), sn (1.0), gacutil (1.0),
which is the inconstent mix I am referring to.

> However, by that logic there is NO way to support the conventional
> "unversioned apps default to the most recent version", unless you
> start introducing alternatives (as with update-alternatives(8), which
> iirc is how many of the Java packages handle things).
> 
> Which is perhaps what we should be doing, relying on the alternatives
> infrastructure...

Well we could (and should) go this route if there is no interest in
solving this right in Mono (using symlinks or the "default scripts").

> 
> > So please lets find a solution that is a) consistent and b)
> > back-wards compatible! (compared to < 2.0 of course)
> 
> Yes, let's find a solution that's consistent.  I personally don't care
> as much about backwards compatibility, because (as mentioned above)
> the current situation is horribly broken (to "newbies") and
> inconsistent with everything else.  If backward compatibility needs
> to be broken, so be it, as long as the result is newby-friendly,
> coherent, and consistent.

I welcome your solution with make all default scripts (without the
version number) pointing to the latest runtime version and supply for
backwards compatibility and other needs the versioned scripts like foo1
and foo2.

But please make sure that we do the _same_ thing with the compiler else
this will not make IMHO anything better.

I need some final decision for this before I can finish the Debian
packages for Mono 2.0, as I have no intention to make the packages ugly
(by using Replaces everywhere) because of moving things to a non-final
solution.

> 
> Another point: not all tools _need_ to be listed under multiple
> profiles.  Take mono-shlib-cop, for example, which looks for all
> DllImport-attribute methods in an assembly and checks that the
> specified library is actually loadable.  Unless you need to run this
> on mscorlib.dll, it doesn't matter if it's a 2.0-profile app, as it
> can still load 1.0 assemblies.  However, if it were a 1.0-profile
> app, it could NOT load 2.0 assemblies, so only providing a 2.0
> version makes perfect sense.  (Except it results in a "movement" of
> the program from mono-1.0-devel to mono-2.0-devel, but this is a
> user-friendly change, and I'm not sure how otherwise to handle it...)

ACK, not all tools really need a 1.0 and a 2.0 version, anything that
reads or produces something (like assemblies) should though, as it might
be incompatible otherwise.

> 
>  - Jon
> 
> 

-- 
Regards,

Mirco 'meebey' Bauer

PGP-Key ID: 0xEEF946C8

FOSS Developer    meebey at meebey.net  http://www.meebey.net/
PEAR Developer    meebey at php.net     http://pear.php.net/
Debian Developer  meebey at debian.org  http://www.debian.org/