On 3/22/07, Vit Hrachovy <[EMAIL PROTECTED]> wrote:
On Tue, Mar 20, 2007 at 03:32:14PM -0700, Dan Kegel wrote:
> >Given list of manual steps required to install Oblivion
> >http://www.uesp.net/wiki/Oblivion:Linux
> >this can be automated easily ...
>
> The problem that wine developers have with recipies
> like the one you cite is that most of the steps in
> the recipe are there to work around bugs in Wine.
> We would prefer to fix the bugs. For instance,
> the steps related to sound and winecfg should just
> go away, hopefully this summer. Likewise with directx
> and registry settings.
>
> That said, I'm certainly in favor of helping users,
> as long as it's done 'right', for some hard to pin down
> definition of 'right'.
> - Dan
Hi Dan,
I understand the WINE developers' attitude for such temporary fixups as
listed above in Oblivion in Linux Wiki.
However, usage scenarios for automated SW installer applications offer far more.
First, it somehow mirrors info from AppDB. It can display application usability
for
range of WINE versions and also make available application on older WINE
versions.
For example Ubuntu Dapper Drake (6.06) will distribute and support Wine
0.9.9 for four years from now.
Second, using automated tools, regression tests can be fully automated,
so building a repository of free game demos or applications is just a
matter of time. Packages can be suited to fit specific WINE versions
or made generic. Install scripts can fully automate / simulate 'normal'
Windows installation process.
Creating regression testing DB is going hand in hand with package
installer creation, so costs are low to nothing.
Automated regression testing could be a big plus of these solutions.
WINE would profit greatly from this.
Third, having list of 'hacks' stored in 'unified' manner within
repository simplifies access to 'fixups' for outstanding issues. At
least they will be at one place (similar to AppDB now).
-----
I've been thinking heavily before I've started participating on
Wine-Doors and coding on Winebot. I've made conclusion that I cannot
hurt WINE, given the potential of these automation tools.
If you are making it extremely easy for users to run with native dlls
and hacky workarounds, then you are hurting Wine. Wine is still beta,
and we need as much testing and bug reporting as possible. You take
away users that help the development process, and attach them to your
project so that when they have a problem with app xyz, they file a
report with your project, not Wine, and you add the necessary hack to
make it work for them. In short, you leech off the hard work of all
the Wine developers and give nothing back in return (quite the
opposite in fact). If you have any reason to believe that you are
helping Wine, I'd sure love to hear it.
--
James Hawkins
