Winebot / Wine-Doors Was: Road to 1.0

[Jan Zerebecki]

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