> Sadly this is the case, but it's no different than how we operate > currently with every installer (Medsphere, Mono, Pidgin, etc) bringing > in their own version of Gtk+, Gtk# and friends.
> > It would be great if there was a better solution, but the main focus of > merge modules *for Medsphere and Novell/Mono* is to share the > maintenance responsibilities for developing installers. If this whole > thing works out, Medsphere will be maintaining a Gtk+ merge module, and > Novell would maintain the Gtk# one. Then, Novell and Medsphere will > build their own installers that bring in the modules that they want > without duplicating tons of effort. I think there is a better answer. I believe if you have been working hard on preparing merge modules, those modules can easily be converted to full installer files. These can form the base of the official Gtk distribution for Win32. If we can agree on installation location for Gtk and it's dependencies, versioning requirements, and perhaps having the Wix files in Gtk+ upstream, then these MSI files can be a dependency of future MSI files generated for Gtk# and Mono. This is a subject I'd really like to talk about. I had created some MSI files for the Gtk stack which I never saw through to completion. During that process I came across some ideas and best practices I thought would really make them polished. Are you available on some sort of IRCish medium or something? > <snip> > > > Microsoft recommends that you create a .msi file for each primary > > distributable (Gtk, Gtk#, Mono, etc) and have the application > > distributor build a bootstrapper which references these .msi files > > independently. VS2005 has a setup project built in which does this: it > > automatically generates a bootstrapper that installs .Net itself. > > Interesting -- I'll look into this approach. > > -Brad > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list