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.<br><br><div><span class="gmail_quote">On 3/14/07, <b class="gmail_sendername">
Stefan Dösinger</b> <<a href="mailto:stefandoesinger@gmx.at">stefandoesinger@gmx.at</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am Mittwoch 14 März 2007 20:01 schrieb Dan Kegel:<br>> I haven't been villified yet, so let me try harder. Should winetricks<br>> be committed to the winehq tree? It would be handy for people<br>> triaging Wine bugs to see if
e.g. native dcom, odbc, or corefonts<br>> hide a bug.<br>I haven't deeply looked at it yet(only the application list), but I am not<br>sure what the answer is.<br><br>For one part it is dangerous that people start using it to install native dcom
<br>and ignoring dcom bugs. Though considering the complexity of dcom, I don't<br>think that anyone who does not know why he/she should not use native dcom<br>would suddenly start fixing builtin dcom bugs. But it would reduce the number
<br>of regression testers and regression reporters because it would be much<br>easier to switch to native dcom than to bisect and report a dcom regression.<br><br>I think the other things like the vbo runtime, odbc drivers, ..., are out of
<br>scope for wine anyway, so no danger in that.<br><br>Appart of dcom I'd say yes. With dcom I can't really answer this :-/<br><br><br><br><br></blockquote></div><br><br clear="all"><br>-- <br>Cheers,<br>Bryan