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 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.
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
