Vitaliy Margolen schrieb:

So, Tom, could you please specify the place where I can redirect all the
people who having problems _with winetools_? To wine-users I presume? As
it looks to me that's the place where all the advertisement going on
about using winetools.

Why not to wine-users? Winetools is a tool from wine users to wine users, and so that list. As it looks to me it is not flooded by winetools questions. If it's getting the upper hand, we can discuss a separate mailing list, but I don't think this happens.

Also had an interesting case last night: person had problems with
winetools. When I asked the version, he said it's 3.0.9. So, there is your
problem. Some one packaged winetools and made this version number.

We renumbered winetools version from 2.xx to 0.9 to be near to the version number of wine. The "3" has technical reasons for making winetools updatable with debians apt-get. So 3.0.9 is winetools 0.9.

As far as winetools go. I see a really bad patterns there.
1. There is no clean way to install them for a local user to test.
   Winetools are invasive and change too many things and go into to many
   places. This is not the way to package software.

It is installable for root like most rpms. It is installing its files to /usr/local/winetools/ and some links to /usr/local/bin. Similar is done by wine. Of course it is making changes to .wine and some places in the home dir when started, but that's necessary for its intention.

Furthermore there are install/uninstall script, both for the tar.gz and the rpm.

2. It can't use wine from the source tree (again for testing).

It should. What were your problems?

3. It's using redundant scripts to like findwine. For what purpose?

It makes some checks to avoid problems. It was not our goal to write perfect code like wine. So it is titled "3rd Party Tools".

4. Those scripts override environment variables that wine and wine parts,
   depend on. Why?

Can you say more precisely what code fragment do you mean?

5. It adds some extra needless overrides to the registry, like
   DLLOVERRIDES="*=native, builtin". Is there a reason for this? That
   _is exactly_ what we, developers, trying to avoid.

Using as much native dlls as possible makes chances best to install windows software, of course not user32.dll and such.

6. "Version"="win98" - that is wrong. Wine's default _is_ win2k.

It is right for the goal of the winetools. Again, this is why it's titled "3rd Party Tools".

Please, we do not need this "quality" "software" linked to from the main
download page.

Once a wise person said to me: "Software is good when it is used".

Sven



Reply via email to