Winebot / Wine-Doors Was: Road to 1.0

[James Hawkins]

On 3/22/07, Jan Zerebecki <jan.wine at zerebecki.de> wrote:
> 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)?
>

Please keep Winebot (or any non-Wine project) development discussion
on the appropriate Winebot mailing list.

-- 
James Hawkins