Philip V. Neves wrote:
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.
[Snip]
Something that allows the AppDB maintainers to distribute tweeks tothe 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.
I grudgingly have to agree that winecfg is at least partly inadequate. One of the things it is lacking is an export and and import function. I do not know how many times I have "blown away" my .wine directory. It would certainly save me some time if I could export the settings for a program and import them later.
If we had the ability to import and export the settings for a program then it would also be possible for someone to upload that file somewhere (lets say the AppDB) and someone else could download it and use the same settings.
The one problem that I can see with this is in the DLL overrides section. That is: if the import file contains a DLL override and the person does not have that dll installed we have a problem. Probably the best idea would be to search in the windows directories and warn the user if it could not find that file.
Of course this does not address actually getting these dlls which is part of what WineTools does.
Tony Lambregts