Just asking for a small enhancement - long story short - I had to run an application depending on .NET and I spend a lot of time 'debugging' why wine-mono wasn't working when I finally noticed that it required wine compiled with mono use flag enabled in order to work, which I have disabled globally.. So this is just to prevent some potential frustration on the user side in the future.
We should already have a message, are you looking for something else? * Messages for package app-emulation/wine-staging-7.6-r1: * Applying the Wine-Staging patchset. Any bug reports to the * Wine bugzilla should explicitly state that staging was used. * Without Wine Mono, wine prefixes will not have a default * implementation of .NET. Many windows applications rely upon * the existence of a .NET implementation, so you will likely need * to install an external one, like via winetricks
(In reply to Nick Sarnie from comment #1) > We should already have a message, are you looking for something else? > > * Messages for package app-emulation/wine-staging-7.6-r1: > > * Applying the Wine-Staging patchset. Any bug reports to the > * Wine bugzilla should explicitly state that staging was used. > * Without Wine Mono, wine prefixes will not have a default > * implementation of .NET. Many windows applications rely upon > * the existence of a .NET implementation, so you will likely need > * to install an external one, like via winetricks I use wine for 2 old games and 2 apps I need for work, neither require .NET and frankly last time I paid any attention during upgrade was when the original wine package was split into different 'flavours' (i.e. everything worked so..). I realize it's just matter of 'paying attention' but hear me out. Wine has use flag 'mono', if you enable it, nothing actually happens, worse, you still need to install wine-mono and you won't actually see above message so you might not be aware you need it. IMHO that's not what you would expect, for (not related) example - 'ssl' might enable encryption support, 'plugins' might enable plugins support, you would expect 'mono' to actually enable .NET support, so it should pull wine-mono for user convenience more than anything else - I suppose it's a bit of downside of using it with combination with RDEPEND. Perhaps mscoree should be enabled by default, afaik it doesn't actually do anything on it's own nor does it pull any dependencies and using 'mono' should just pull wine-mono directly ? Unless it's somehow messing with newer versions (not supported by mono). On the wine-mono side - perhaps just a warning you need wine[mono] ? I hope I managed to explain my 'gripe' with current status quo.
Sorry, I'm not sure I understand, USE="mono" does pull in wine-mono in RDEPEND mono? ( app-emulation/wine-mono:7.2.0 ) If you have +mono set portage will install wine-mono when you emerge wine-{vanilla,staging} If not, it will print a warning saying you probably want mono.
(In reply to Nick Sarnie from comment #3) > Sorry, I'm not sure I understand, > > USE="mono" does pull in wine-mono in RDEPEND > > mono? ( app-emulation/wine-mono:7.2.0 ) > > If you have +mono set portage will install wine-mono when you emerge > wine-{vanilla,staging} > > If not, it will print a warning saying you probably want mono. Duh, my fault, I don't know why thought it would not, probably was confused because I installed wine-mono before reinstalled wine/assumed it will pull wine[mono] like other packages.
No problem, what probably happened is that you had USE=-mono globally and didn't see the message from the ebuild
