So, I've finally had some time to work on Mono packaging. I think I have a sort of "first draft" ready. The goal is to create an MSI package of Mono, similar to the one we use for Gecko, which Wine will install automatically when updating a prefix, unless native mscoree is installed. This package will include all the Mono runtime files, as well as any registry keys and files that need to be installed to the Windows system for .NET compatibility. Anything .NET that we want to replace (including XNA, WPF, and msvcm libraries) will be included. Ideally, with this package installed, any official installers for .NET components will decide they are already installed and do nothing. To install native .NET, it will be necessary to uninstall the Mono package (using "wine uninstaller --remove '{E45D8920-A758-4088-B6C6-31DBB276992E}'", which will continue to work for the foreseeable future). Before the Mono package is installed, and after it is removed, no .NET registry keys or files will be present, so in theory the installers will just work (but in practice they probably will require work-arounds for Wine bugs). There will be only one package for 32-bit and 64-bit. Most of the compiled code is architecture-independent, so it doesn't make much sense to have separate packages. The Mono package versions will be loosely tied to Wine version. On prefix creation time, Wine will attempt to install the version it "prefers". Due to limitations of MSI, this may mean that Wine will upgrade Mono automatically but never downgrade it. Because the Mono API is stable, it should be possible to use any Mono package with any Wine version back to 1.5.1, which was the first version to search for the Mono runtime dll based on architecture. I'm currently publishing the source code at https://github.com/madewokherd/wine-mono, but I'm not sure if that is a good permanent home. I do want to keep it on github so I can make and accept pull requests. I'm using submodules, so it will be necessary to clone with --recursive and update the submodules from time to time. The build process requires mingw-w64 (both 32-bit and 64-bit), Wine, and a version of the Mono C sharp compiler (gmcs or dmcs, I think), and not surprisingly is done by running build-winemono.sh. There should never be any more requirements, and I'd like to keep the version requirements on those as broad as I can. I want this to be easy to build, so other people can work on it. The 64-bit part appears to work on Windows, but it is not useful on Wine currently. I'll be working on fixing that, or at least getting Alexandre bug reports and test cases so he can work on it. I think that when it is fixed, we'll have a lot more 64-bit processes than we used to, for better or worse. For now, the only way to install the package is with msiexec. The current version is based on Mono 2.11.0, which has a serious deadlock bug on Windows. This will need to be resolved before I can do an actual release. Otherwise, I'm not expecting much difference from the official Mono 2.10 packages for Windows. The XNA, WPF, and msvcm stuff is not ready yet. So, I know it's kind of crappy right now, and I'm not asking for testing so much as comments. If you are a packager of Wine, I would like to make sure you can build it, and that the resulting build works apart from that deadlock bug. If for some reason you want to try it, the current version is at https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. I think I will need a new home for the binaries, because github only gives me enough space for about 5 of them. So, uh, don't count on that URL sticking around.
On Wed, Apr 18, 2012 at 11:12 PM, Vincent Povirk <madewokherd(a)gmail.com>wrote:
If for some reason you want to try it, the current version is at https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. I think I will need a new home for the binaries, because github only gives me enough space for about 5 of them. So, uh, don't count on that URL sticking around.
You can probably message the github staff to get a space increase. IIRC they can special-case open source projects that need more space. J. Leclanche
Hi Vincent, On 04/19/12 00:12, Vincent Povirk wrote:
If for some reason you want to try it, the current version is at https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. I think I will need a new home for the binaries, because github only gives me enough space for about 5 of them. So, uh, don't count on that URL sticking around.
The right place for this is probably SourceForge, like all our other downloads. That's a detail to be handler during the final release through. Cheers, Jacek
On 4/19/12 1:54 AM, Jacek Caban wrote:
Hi Vincent,
On 04/19/12 00:12, Vincent Povirk wrote:
If for some reason you want to try it, the current version is at https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. I think I will need a new home for the binaries, because github only gives me enough space for about 5 of them. So, uh, don't count on that URL sticking around.
The right place for this is probably SourceForge, like all our other downloads. That's a detail to be handler during the final release through.
Cheers, Jacek
Sourceforge only gives us limited space that you can get through via a simple web URL. If we need Wine to automatically download this the way it does Gecko, then doing a normal "release" via sourceforge might not be enough (since Wine can't click through the page). This is why we were using things like the budgetdedicated hosting service (which is still available) in years past. Thanks, Scott Ritchie
On 4/20/12 11:29 PM, Scott Ritchie wrote:
On 4/19/12 1:54 AM, Jacek Caban wrote:
Hi Vincent,
On 04/19/12 00:12, Vincent Povirk wrote:
If for some reason you want to try it, the current version is at https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. I think I will need a new home for the binaries, because github only gives me enough space for about 5 of them. So, uh, don't count on that URL sticking around.
The right place for this is probably SourceForge, like all our other downloads. That's a detail to be handler during the final release through.
Cheers, Jacek
Sourceforge only gives us limited space that you can get through via a simple web URL. If we need Wine to automatically download this the way it does Gecko, then doing a normal "release" via sourceforge might not be enough (since Wine can't click through the page). This is why we were using things like the budgetdedicated hosting service (which is still available) in years past.
I'm not sure what limited space you mean. We already have Wine Gecko on SourceForge and a redirecting script on source.winehq.org, which is used for automated downloads. AFAIK this way we don't have any limitations and, as far as Wine packages are concerned, we don't depend on any specific external mirror provider. Jacek
On 4/23/12 1:45 AM, Jacek Caban wrote:
On 4/20/12 11:29 PM, Scott Ritchie wrote:
On 4/19/12 1:54 AM, Jacek Caban wrote:
Hi Vincent,
On 04/19/12 00:12, Vincent Povirk wrote:
If for some reason you want to try it, the current version is at https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. I think I will need a new home for the binaries, because github only gives me enough space for about 5 of them. So, uh, don't count on that URL sticking around.
The right place for this is probably SourceForge, like all our other downloads. That's a detail to be handler during the final release through.
Cheers, Jacek
Sourceforge only gives us limited space that you can get through via a simple web URL. If we need Wine to automatically download this the way it does Gecko, then doing a normal "release" via sourceforge might not be enough (since Wine can't click through the page). This is why we were using things like the budgetdedicated hosting service (which is still available) in years past.
I'm not sure what limited space you mean. We already have Wine Gecko on SourceForge and a redirecting script on source.winehq.org, which is used for automated downloads. AFAIK this way we don't have any limitations and, as far as Wine packages are concerned, we don't depend on any specific external mirror provider.
Perhaps I am misremembering bandwidth limitations as space ones, but I do recall that hosting the Ubuntu packages there simply did not work once we had more than a few thousand users long ago. Depending on how frequent a download mono is, we may run into the same issue (with a similar solution: most Ubuntu users don't ever hit the sourceforge gecko download because they get gecko from an automatically installed package that comes with the Wine package) Thanks, Scott Ritchie
participants (4)
-
Jacek Caban -
Jerome Leclanche -
Scott Ritchie -
Vincent Povirk