[mono-packagers] Startup Scripts Inconsistency in Mono 2.0

Jonathan Pryor jonpryor at vt.edu
Sun Oct 19 16:47:10 EDT 2008


On Sun, 2008-10-19 at 17:00 +0200, Mirco Bauer wrote:
> in Mono 2.0 I noticed a serious inconsistency in the startup scripts.
> This makes is very difficult to package it correctly, as I am splitting
> applications that target the 1.0 and 2.0 runtime.

Perhaps unsurprisingly, I don't consider this to be a serious
inconsistency.  I consider it a necessary evil to move on and follow
convention.

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?

As far as I'm aware, for ~every "platform"/program that allows multiple
versions to be installed, the "versionless" program name is always the
most recent version of the program.

Except for Mono.  Which makes ~no sense to me.  Mono is the exact
opposite of ~everyone else -- instead of "opting in" to a *previous*
version, you "opt in" to the *current* version.  It's ass-backwards.

Because of things like this, we have for _years_ had people who thought
Mono didn't support generics because mcs was restricted to the 1.x
profile.  Ditto for xsd and everything else.  NO ONE thinks to
themselves "xsd doesn't support my generics code; perhaps I should use
xsd2" (because most of the time they're not going to know xsd2 exists,
much less that they should look  for it).  If we're *lucky*, they'll pop
in on IRC and we can tell them what they're doing wrong.

Except they're not doing anything wrong, *Mono* is doing something
wrong, by not following convention.

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.

> It seems that most scripts without a version number are now call the 2.0
> version instead of the 1.0 version.
> 
> I see major issues with this though as there are many applications that rely
> on this scripts during the build, and suddenly the helper tools start using
> the 2.0 profile and not 1.0 like they did before.

This is a necessary evil in order to fix Mono's broken-ness as described
above.

> As example if an application builds using mcs and al, al is now 2.0 while
> mcs (as expected) 1.0....

Which wouldn't be a problem if mcs targeted 1.0 at the same time. :-)

> IMHO all development tools should ship 2 flavors (1.0 and 2.0) with 2 scripts
> (one for 1.0 and one for 2.0) and a default script that either calls 1.0 for
> _all_ scripts or 2.0, but not a mix between of that!

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.)

> This is not only a build issue but also a packaging issue, as files shipped
> in packages (at least for debian) are not allowed to overwrite files of other
> packages (if not explicitly allowed). Thus making /usr/bin/al suddenly use /usr/lib/mono/2.0/al.exe
> means the script has to be moved from mono-1.0-devel to mono-2.0-devel and existing
> source packages in debian will now break as they have a build-dependency on
> mono-1.0-devel and not mono-2.0-devel.

This is bad.

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...

Thus e.g. mono-1.0-devel would ship al1, and mono-2.0-devel would ship
al2, and both would use /etc/alternatives to decide which file `al`
refers to.

Would this break existing packages?  Possibly (probably?).  But I also
don't see how this is any different from what other systems require --
e.g. if you depend upon `javac`, which version is that?  Java 5.0, or
6.0?  I don't actually know the packaging answer to that, but I do
realize that the scenario already exists, and thus a solution
(presumably) already exists, so if at all possible we should follow
pre-existing convention.

> 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.

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...)

 - Jon




More information about the mono-packagers-list mailing list