I Cc-ed Karl Lattimer from Wine-Doors to also ask him if the provisions detailed here are also compatible with his views of Wine-Doors.
Something like Winebot could possibly save me much time while testing and developing. I reinstalled certain applications or workarounds countless times, automating it thus would make working on Wine less tedious. So I really want something like Winebot to be compatible with developing on Wine and to be something we could safely recommend to users and developers.
It could make it easier to check if a bug is valid: Imagine there may be a command like:
WINEPREFIX=~/apps/wine-foo winebot install --clean foo
The argument --clean makes sure that the wineprefix does not exist before the install starts (refuses to proceed otherwise). It then would print to stdout that the wineprefix does not exist, the wine version, the winedoors version and the URL and possible other identification of the Winebot recipe (and probably other things during the install). So if the user saves the output and attaches it one can instantly rule out many possible errors on the part of the user.
On Thu, Mar 22, 2007 at 10:42:20AM -0700, Dan Kegel wrote:
- My goal in writing Winebot is to help Wine succeed
- I pledge to use only the bare minimum of native DLLs in any Winebot recipe
- I pledge to remove native DLLs from Winebot recipes as soon as Wine
fixes the bugs that keep Wine's DLLs from being sufficient for that app
- I will report bugs to the Wine project in the course of working on Winebot
Having a bugreport for every hack that is used is very important. In my view these points would certainly fix most of the possible problems with something like Winebot.
- I will help Wine by writing not just Winebot recipes, but also
basic application regression test scripts
This would be really nice and would give you much credibility with Wine developers, but it is IMHO not a must. I mean we don't say all patches must be accompanied by tests either.
There are two other possible problems with something like Winebot:
Hacks for one application can interfere with hacks for another application. Setting dll overrides or other hacks only per application might be a good idea, but is error prone (missing some part that need the hack and not properly restricting the hack). The best solution is to have one WINEPREFIX for each application. This can simply be done by needing the environment variable WINEPREFIX set (not defaulting to ~/.wine ) and warning if it is set to ~/.wine .
http://winebot.sandbox.cz/tracker says under "Typical usage scenario": * User runs winebot first time. Winebot asks user for his name, his company name and proceeds to download and install the basic Windows compatibility programs into ~/.wine (or other WINE bottle directory) * After bottle initialization (installation of basic compatibility programs) user is then capable of using winebot to install the packages from winebot repository
Installation of "basic compatibility programs" sounds like it would clash with "only use the bare minimum of native DLLs / hacks in any Winebot recipe". Winebot shouldn't install anything that the application does not need.
Do you think these provisions are compatible with your idea of Winebot (same question for Karl Lattimer and Wine-Doors)?
Jan
PS: The link to wine-doors.org on the top of http://winebot.sandbox.cz/tracker is missing the "s".