2009/11/17 Jacek Caban jacek@codeweavers.com:
I can see three types of Wine users:
- regular users
They use Wine packages that should guarantee presence of Gecko (as Wine dependency or in Wine package, depends on packagers preferences). The current situation will probably force packagers to do the right thing <g>
- Wine developers
I'm surprised how many developers are affected by this change. It means that developers were not aware of the right way to install Gecko (probably because winetricks is too good :-) ). I'm sure it will change now.
- Users who compile Wine themselves
Well... the information about proper Gecko installation is easy to find and it's pointed on every wineprefix creation. They should survive as long as they read what's .
Given that, I think this change will force changes that will allow us to forget about the problem soon.
You're missing a type of user that has been quite vocal on this thread: - Users who have no need for Gecko These are "regular users" who don't use applications or games that require MSHTML/Gecko/IE6/whatever. They don't view .chm files either, and most of them don't run the test suite. This group has been completely forgotten in the decision to force Gecko.
OK, so you can hit "Cancel" to stop the download. This is *not* satisfactory. As it is at the moment, Gecko sits half-way between an opt-in and an opt-out system. It should be made one or the other - either force it to be installed (by all package maintainers) on first install and then have it optionally removed *without* causing a stupid pop-up box saying it's missing, or have a button in winecfg or similar that downloads it if it is missing.
As the maintainer of WineHQ's Debian packages, I have produced a new wine-gecko-1.0 package for use with 1.1.33, something that I was considering for a long time. However, I refuse to force the Wine package to depend on it because this wine-gecko-1.0 package doubles the required download (7.8MB wine-gecko-1.0, 7.8MB wine 1.1.33 package). I realise that this will not be required to download on every upgrade, but I also can't predict when wine-gecko releases are made.
Currently, the wine-gecko-1.0 package I have produced depends on Wine. I may need to rethink this to cater for user groups 2 and 3 above.
Furthermore, I have not yet packaged earlier versions of wine-gecko for use with earlier versions of Wine, but I believe I have had the foresight to think of this potential situation. This is in direct contrast to the obviously low about of thought that went into the change to how Wine downloads Gecko.
2009/11/17 Jacek Caban jacek@codeweavers.com:
You can't *force* the creation of packages which would likely fail to meet the requirements for inclusion into Debian's main archive. Even if I didn't think the package's build system is a problem, the ftpmasters likely would.
Then I can't see better solution for Debian users than downloading Gecko on wineprefix creation. It's not perfect, but we don't have much choice.
It shouldn't even be an option. What's wrong with adding an opt-in button to "winecfg"?
The rigidity of proponents of the "new way" is disheartening. The feeling coming across is "this way is better for everyone because we say it is". If this was something like, e.g., my decision to not separate OpenGL from the core Wine package, it wouldn't be a real problem (OpenGL support is used by the majority of Wine users, and takes up very little space in the binary distrobution), but it's not. Gecko is purely optional (although not recommended, "winetricks ie6" does get some apps working where Gecko doesn't), and quite large.