also installs mono

Max TenEyck Woodbury max at
Mon Jun 4 12:23:21 CDT 2012

On 06/04/2012 03:05 AM, Frédéric Delanoy wrote:
> On Mon, Jun 4, 2012 at 8:35 AM, Dan Kegel<dank at>  wrote:
>> On Sun, Jun 3, 2012 at 11:20 PM, Frédéric Delanoy
>> <frederic.delanoy at>  wrote:
>>> On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegel<daniel.r.kegel at>  wrote:
>>>> now
>>>> also installs mono. ...
>>> Wouldn't it be better (and more acceptable for people
>>> disliking/wanting to avoid mono) to
>>> - keep as is
>>> - create
>>> - create calling the former
>>> ?
>> The point of this script is to make life easier for me and
>> for the average user.  It's not to make life easier for
>> people who don't like mono, mostly because I doubt
>> there are many of them.
> My comment was not only meant for "mono-haters", but it can also be
> useful IMHO to split e.g. to limit download size.when one doesn't even
> need mono, and it maybe clearer as well ("addons" is pretty generic).
> Frédéric

Actually, it really is the name that matters.  'mono' is a lightning
rod for a lot of political history.  If you were to integrate the same
functions into Wine itself, and hopefully avoid tripping over the
stinking Microsoft patents, that set of problems can be avoided,

A native MSWindows application that wants .net support would either
connect to the installed dll that provides the required services or
install such a dll.  It would know nothing about 'mono'.  It is only
non-MSWindows platform programs that will try to link to the
non-MSWinows libraries in 'mono'.

So an MSWindows executable looking for .net support needs .net support,
NOT mono.  We can and should provide such executables the services they
need.  However we should NOT make it easy for programs from other
platforms to fall into the stinking Microsoft Patent trap.  That
gateway to hell is called 'mono' and we should NOT open it.

More information about the wine-devel mailing list