docu update

[Dimitrie O. Paun]

On Sat, Jun 19, 2004 at 10:37:54AM -0700, Alexandre Julliard wrote:
> users build without having to fight the autoconf tools. It's for the
> same reason that we have wineinstall. Of course I'm all for improving
> the binary packages, but it doesn't avoid the need to also support
> source builds.

Supporting source builds, and making them easy, is a worthy goal, 
and we all understand that. We're not arguing to not support them.
Virtually every package out there works with the standard:
	configure; make
We're arguing that wine should work just like that, without
requiring addition wrapper scripts.

Now, you've pointed out some uses cases (namely newbies that need
to build a most recent version), where a wrapper script is useful
to avoid some potential problems. For this use case, it seems to
us that a prepackaged binary would be double useful:
  -- it's easier on the user (let's face it, even if it's only one
     command, compiling Wine is not that fun, it used to take me
     1h and a lot of HD space). In fact, compiling is not the
     problem. The user needs to get the latest CVS tree, install
     devel packages, etc. all of which is a lot more complicated
     then configure; make. Installing a binary package on the
     other hand, is a lot faster, which means that the user will
     more likely go through with the operation.
  -- it's better for us, because we have a controlled build that
     we understand. We can build it so it has all the extensions
     enabled, and do it properly, on a known tool chain. This is
     an important attribute when dealing with a completely clueless
     user, and is in fact important on it's own, apart from the
     current wineinstall discussion.

The rest of source users will be able to deal with the
    configure; make
no problem. The above is by no means complicated.

-- 
Dimi.