docu update

Mike Hearn <mike at navi.cx> writes:
> a) There is no binary package for their distribution. How common is this?
> I don't know but I've encountered a startling number of newbies that use
> off-the-wall distros like Ark/College Linux etc.
>> b) There is but it's out of date or broken. This is worryingly common too
> even in large distros, witness the frequently broken Gentoo Wine packages.
> There are some slackpacks going around currently that (wrongly)
> dynamically link against the X extension libraries causing them not to
> work for many people. These people are often told to "build from the
> source" or "build from CVS".
>> c) They are trying to run a program and it doesn't work either due to
> traditional Wine bugs or distro breakage, so rather than wait for the next
> release they decide to try CVS directly.
d) They need something that isn't part of the standard packages (for
instance BiDi support).
e) They want to report a crash and need debug symbols to get a valid
backtrace.
f) They want to try a patch that someone sent them.
etc.
> (a) and (b) can be solved by WineHQ providing its own distro-neutral, run
> anywhere binary packages. This isn't hard as Wine is generally excellent
> at running on different peoples machines from the same binaries - after
> all, CodeWeavers need it. I think a nice installer for correctly built
> distro-neutral binaries for Wine would go a long way towards cutting the
> number of non-developers building from source down to zero.
I don't see why that should be a goal at all. You guys need to get rid
of the mindset that building from source is some 1337 thing that mere
mortals are not supposed to do. There are plenty of legitimate reasons
for users to build from source, and we need to make sure it works for
them. That's why for instance the configure script is checked into
CVS; it is of course heresy to put generated files in CVS, but it lets
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.
--
Alexandre Julliard
julliard at winehq.org