What I'm seeing here with the whole debate with wine and winetools is that its a configuration management issue. The project is getting into the stage where testing needs to be accomodated and so does getting things working. I think whats currently available for managing configurations to wine is innadequate. Even winecfg provides an interface that is innadequate for making many changes in terms of dll overrides. Plus it doesn't provide a mechanism for rolling those changes back. Or even managing multiple configurations or modes so that problems can be issolated. I think whats is comming out of the winetools debate is better tools are needed for configuration management. This isn't very revolutionary. Its a natural part of the software development life cycle. As a project starts emerging from the development phase ways to provide better configuration management start showing themselves.
Something that interfaces with the AppDB would be good. It would make things easier. I think, given the complaints given by the developers are also valid but so are the complaints made by the people trying to use the program and even the testers. Most other projects don't need such tools but this one does given what its trying to accomplish and the complexity of whats being accomplished. Besides even windows XP has a roll back feature now to fix problems. Why doesn't wine considering its attempting a bug for bug compatibility with windows. This would be a wise thing to implement just for sanities sake.
So I'd like to provide an addition to Jason Greens brain dump
* AppDB would have to be extended to be able to get and report this data, and it would make sense for each App's maintainer to be able to manage that information. * Biggest issue here is that this information could have a tendency to change very rapidly, so it might overload the app maintainers if they had to track this for each version of wine. What I think would make sense is to have regular snapshots (every 3 months?) and release a new version of "Winetools Plus" or whatever you want to call this thing a month later to give the maintainers time to update each of their apps based on the frozen version. (I think multiple versions of the AppDB would be useful. Similar to the Release and Release candidate type way of doing things.) * Data needed: AppID, AppVersionID, WineVersionID, Window Version, DLL Overrides, Window settings (fullscreen/windowed - sometimes and issue), Sound options, Video acceleration required, General notes or HOWTO's, etc. You would need separate overrides/settings for Installing vs. Running the app. * AppDB could dump this information to an xml format which "Winetools Plus" could be distributed with. Maybe have an option to download the latest xml file directly from winehq.org. * The 'Winetools Plus' front-end would just be a menu which would query all of the apps in the xml dump. The user picks they app they want to install, and it reads the necessary information, verifies the source installation media, and goes at it. * Applying patches to apps might get tricky (e.g., where wine only successfully runs version 1.5 of the app, but 1.0 is on the CD), but I'm sure it could be worked out. * A Way to roll back DLL overrides. * A Way store roll multiple registry configurations so that we establish a base reference configuration and a test configuration. Or even multiple test configurations. * An AppDB tool that allows changes to the DLL configuration in the AppDB to be made easily. * A way to detect the version of wine and provide configuration changes given that version of wine. * A way to report bugs to the appDB maintainers about configuration problems.
A nice to have would be
Something that allows the AppDB maintainers to distribute tweeks to the configuration changes in the AppDB to users. So that even if we aren't installing the programs on the system. The tweeks can still be made on the fly. This would eliminate having to blow away the .wine directory all the time. Blowing away the .wine directory is not a desirable. A way for wine developers to distribute a test configuration would also be a useful thing. That way we can test the software with what the developers want us to test rather then shooting in the dark only to see that the bug we reported is the same as some other bug we reported.
Such tools would be useful in debugging the entire framework and speed up development. These are suggestions. I hope they help a bit.