Submitting winetricks to winehq tree?
I haven't been villified yet, so let me try harder. Should winetricks be committed to the winehq tree? It would be handy for people triaging Wine bugs to see if e.g. native dcom, odbc, or corefonts hide a bug. I've uploaded a new version to http://kegel.com/wine/winetricks Mainly it adds a -q option to make all the installers quiet, but it also includes lots of little improvements sent in by Detlef and Saulius. Here's the new usage message: Usage: winetricks [options] package [package] ... This script can help you prepare your system for Windows applications that mistakenly assume all users' systems have all the needed redistributable runtime libraries or fonts. Options: -q quiet. You must have already agreed to the EULAs. -v Verbose Packages: art2kmin Access 2000 runtime. License required! corefonts Install MS Times, Arial fonts dcom98 Install native DCOM, override the Wine implementation fakeie6 Set registry to claim IE6sp1 is installed mdac27 Microsoft ODBC drivers, etc. mfc40 mono1.1 mono 1.1.13-gtksharp-2.8.2 mono1.2 mono 1.2.3.1-gtksharp-2.8.3 vbvm50 Visual Basic 5 runtime vbrun60 Visual Basic 6 runtime vcrun6 vc6redist from VS6sp4, including mfc42 wsh51 Windows Scripting Host 5.1
Am Mittwoch 14 März 2007 20:01 schrieb Dan Kegel:
I haven't been villified yet, so let me try harder. Should winetricks be committed to the winehq tree? It would be handy for people triaging Wine bugs to see if e.g. native dcom, odbc, or corefonts hide a bug. I haven't deeply looked at it yet(only the application list), but I am not sure what the answer is.
For one part it is dangerous that people start using it to install native dcom and ignoring dcom bugs. Though considering the complexity of dcom, I don't think that anyone who does not know why he/she should not use native dcom would suddenly start fixing builtin dcom bugs. But it would reduce the number of regression testers and regression reporters because it would be much easier to switch to native dcom than to bisect and report a dcom regression. I think the other things like the vbo runtime, odbc drivers, ..., are out of scope for wine anyway, so no danger in that. Appart of dcom I'd say yes. With dcom I can't really answer this :-/
It looks a lot like a command-line version of what wine-doors aims to be, right? Only the installing software aspect, and not the dynamic aspect of repositories and such. On 3/14/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Am Mittwoch 14 März 2007 20:01 schrieb Dan Kegel:
I haven't been villified yet, so let me try harder. Should winetricks be committed to the winehq tree? It would be handy for people triaging Wine bugs to see if e.g. native dcom, odbc, or corefonts hide a bug. I haven't deeply looked at it yet(only the application list), but I am not sure what the answer is.
For one part it is dangerous that people start using it to install native dcom and ignoring dcom bugs. Though considering the complexity of dcom, I don't think that anyone who does not know why he/she should not use native dcom would suddenly start fixing builtin dcom bugs. But it would reduce the number of regression testers and regression reporters because it would be much easier to switch to native dcom than to bisect and report a dcom regression.
I think the other things like the vbo runtime, odbc drivers, ..., are out of scope for wine anyway, so no danger in that.
Appart of dcom I'd say yes. With dcom I can't really answer this :-/
-- Cheers, Bryan
On 3/14/07, Dan Kegel <dank(a)kegel.com> wrote:
I haven't been villified yet, so let me try harder. Should winetricks be committed to the winehq tree? It would be handy for people triaging Wine bugs to see if e.g. native dcom, odbc, or corefonts hide a bug.
I've uploaded a new version to http://kegel.com/wine/winetricks Mainly it adds a -q option to make all the installers quiet, but it also includes lots of little improvements sent in by Detlef and Saulius.
Here's the new usage message:
Usage: winetricks [options] package [package] ... This script can help you prepare your system for Windows applications that mistakenly assume all users' systems have all the needed redistributable runtime libraries or fonts.
Options: -q quiet. You must have already agreed to the EULAs. -v Verbose Packages: art2kmin Access 2000 runtime. License required! corefonts Install MS Times, Arial fonts dcom98 Install native DCOM, override the Wine implementation fakeie6 Set registry to claim IE6sp1 is installed mdac27 Microsoft ODBC drivers, etc. mfc40 mono1.1 mono 1.1.13-gtksharp-2.8.2 mono1.2 mono 1.2.3.1-gtksharp-2.8.3 vbvm50 Visual Basic 5 runtime vbrun60 Visual Basic 6 runtime vcrun6 vc6redist from VS6sp4, including mfc42 wsh51 Windows Scripting Host 5.1
I don't think winetricks should be a part of the Wine tree. It's a great developer tool, but it could potentially be abused by users to run with native libs like IE, DCOM, MSI, etc more so than they would otherwise. The fact that the script downloads and installs non-free software, especially from Microsoft, is a connection that we should not accept "officially" by committing it to the tree. All of that aside, it's a nice script that has been very useful for debugging, and I'm sure others find it equally useful. -- James Hawkins
Hi, On 14.03.2007 20:01, Dan Kegel wrote:
I haven't been villified yet, so let me try harder. Should winetricks be committed to the winehq tree? It would be handy for people triaging Wine bugs to see if e.g. native dcom, odbc, or corefonts hide a bug.
Sorry if this has been answered before, but is winetricks a newer version of winetools? Regards, Carl-Daniel
participants (5)
-
Bryan Haskins -
Carl-Daniel Hailfinger -
Dan Kegel -
James Hawkins -
Stefan Dösinger