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 <[EMAIL PROTECTED]> 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
