"Ivan" <puoti(a)inwind.it> writes:
This patch has been written thinking that a) it's better to have no doc than an out of date one and b) most of the stuff that's commented out can be easily re-written before the next release (I have school holidays until september so I have lots of time to do this).
wineinstall is not out of date, it still works fine, I don't see any reason to remove it from the doc. -- Alexandre Julliard julliard(a)winehq.org
On Fri, Jun 18, 2004 at 11:26:33AM -0700, Alexandre Julliard wrote:
wineinstall is not out of date, it still works fine, I don't see any reason to remove it from the doc.
It's true, wineinstall works OK, but AFAIK we've decided to remove it sooner rather then later, and I guess now it's a good enough time (given that it doesn't do anything interesting anymore). So looking into the future, wineinstall is deprecated, so we'd better not recommend people use it, it will create more pain when we do actually remove it. -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
It's true, wineinstall works OK, but AFAIK we've decided to remove it sooner rather then later, and I guess now it's a good enough time (given that it doesn't do anything interesting anymore). So looking into the future, wineinstall is deprecated, so we'd better not recommend people use it, it will create more pain when we do actually remove it.
I don't see why we have to remove it at all. We have to remove most of its contents, sure, but even if all it does is wrap "configure;make" with some user-friendly messages it has some value IMO. -- Alexandre Julliard julliard(a)winehq.org
On Fri, Jun 18, 2004 at 12:22:10PM -0700, Alexandre Julliard wrote:
I don't see why we have to remove it at all. We have to remove most of its contents, sure, but even if all it does is wrap "configure;make" with some user-friendly messages it has some value IMO.
To be honest, I would be very happy if we can get rid of it. Let me try to explain why: -- few people still build from source. The stats on SF show that only 15% of people get the source tarball, and there are good reasons for this. -- of the few who do d/l it as tarballs, most are power users that don't need/want a basic wrap around "configure;make" -- it is another abstraction that is unfamiliar to people, that needs to be understood for little gain. For the last point, I'll tell you my experience with such wrappers. First, I try to avoid as much as possible installing software that is not package. On my system, the _only_ such package is wine since I work on it. I will not try to justify it, suffices to say that most people do the same, as shown by the stats. In the few occasions that I had to (in the past) compile from .tar.gz, I was quite frustrated by packages that did not follow the standard configure; make approach. Yes, maybe their little script was more convenient, but for me was a pain: -- I did not trust them. Why did they need a scipt? Why not follow the standard. I know, technically it makes no sense, but a psychological level that was my reaction. Go search and do extra work to (1) see what their script does, and (2) try to use the standard install method. -- once done, I did not have a warm and fuzzy feeling. Did I miss something? Should I have used their prefered method instead? Etc, etc. Providing two ways for such a standard thing is not a good idea. It's a matter of UI, and I've argued in the past that almost always it's better to follow the known standard even unless you think you can improve considerably. Having just a trivial wrapper around "configure;make", and advartising it in the documentation before the well known standard does not do that IMO. Let's remove it and see if people complain, and why they complain. We are likely to find real problems that need fixing anyway. -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
Let's remove it and see if people complain, and why they complain. We are likely to find real problems that need fixing anyway.
That's easy, they will complain about the thing wineinstall takes care of, like not having write access to the build tree, conflicts with the installed rpm, missing ld.so.conf entry, etc. These things were added to wineinstall precisely because many people complained about them. The alternative is to add all these checks in configure and the makefiles, but then it annoys experienced users who know what they are doing and get treated as if they didn't. I think having different levels of hand holding for different users makes a lot of sense, and wineinstall gives us that possibility. -- Alexandre Julliard julliard(a)winehq.org
Le ven 18/06/2004 à 17:44, Alexandre Julliard a écrit :
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
Let's remove it and see if people complain, and why they complain. We are likely to find real problems that need fixing anyway.
That's easy, they will complain about the thing wineinstall takes care of, like not having write access to the build tree, conflicts with the installed rpm, missing ld.so.conf entry, etc. These things were added to wineinstall precisely because many people complained about them.
The alternative is to add all these checks in configure and the makefiles, but then it annoys experienced users who know what they are doing and get treated as if they didn't. I think having different levels of hand holding for different users makes a lot of sense, and wineinstall gives us that possibility.
./configure --without-hand-holding could skip over those tests, and they would be there for a straight ./configure. It wouldn't have to be very documented... Vincent
On Fri, Jun 18, 2004 at 07:26:23PM -0400, Vincent Béron wrote:
Le ven 18/06/2004 à 17:44, Alexandre Julliard a écrit :
That's easy, they will complain about the thing wineinstall takes care of, like not having write access to the build tree, conflicts with the installed rpm, missing ld.so.conf entry, etc. These things were added to wineinstall precisely because many people complained about them.
./configure --without-hand-holding could skip over those tests, and they would be there for a straight ./configure. It wouldn't have to be very documented...
I don't think we should do that. First of all, none of the problems mentioned are wine specific, and I don't think we need to try to fix them like that. Second, as I have already argued, it seems most of our builders from source are already power users, and are most likely used to the configure; make cycle well enough that they don't need the hand holding. In fact, they most likely hate it (as I do). The Linux user landscape has changed quite a bit lately, to the point where having wineinstall probably does more harm than good. -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
I don't think we should do that. First of all, none of the problems mentioned are wine specific, and I don't think we need to try to fix them like that. Second, as I have already argued, it seems most of our builders from source are already power users, and are most likely used to the configure; make cycle well enough that they don't need the hand holding. In fact, they most likely hate it (as I do). The Linux user landscape has changed quite a bit lately, to the point where having wineinstall probably does more harm than good.
What harm do you think it causes? Have you heard of anybody complaining? Why would any power user run wineinstall if they really hate it? Maybe Linux users in general know how to run configure (though I doubt that), but that's definitely not true for Wine users IMO; most of them come straight from Windows, and Wine is often the first time ever they build something from source. We have to make it easy for them. I want to be able to say to a user who reported a bug "please try latest CVS and confirm that it is fixed" without having to tell them about configure or LD_LIBRARY_PATH or whatever. Maybe you don't have clueless users asking you how to build Wine, but I get quite a bit of them; and being able to tell them "just run tools/wineinstall" saves me a lot of grief. -- Alexandre Julliard julliard(a)winehq.org
configure or LD_LIBRARY_PATH or whatever. Maybe you don't have clueless users asking you how to build Wine, but I get quite a bit of them; and being able to tell them "just run tools/wineinstall" saves me a lot of grief.
That's a fair argument, and I can understand that. If it saves you time and agravation, it's worth it. I guess my main concern is having wineinstall in the main flow of the documentation. You're asking:
What harm do you think it causes? Have you heard of anybody complaining? Why would any power user run wineinstall if they really hate it?
Well, as I've tried to explain, when I see stuff like this, I'm always left with lingering questions: if I run the standard method (configure;make) that I like, I'm wondering wether I've missed something important. Are the bugs I'm seeing caused by me not running wineinstall? If I do run wineinstall, I do it against my first impulse so to speak, and then I keep wondering why the heck couldn't they just stick to the standard method. I can't speak for others, but for me it's annoying (in projects that I just install, not wine where I know what's going on). Normally I'd suggest that clueless users use a packaged wine instead, but you have a good point about building the latest CVS. Hmmm. Maybe making it less proeminent in the documentation, but still keeping it around so you can point users to it? Blah, maybe you're right, and people can't really run configure; make Shame. -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
Well, as I've tried to explain, when I see stuff like this, I'm always left with lingering questions: if I run the standard method (configure;make) that I like, I'm wondering wether I've missed something important. Are the bugs I'm seeing caused by me not running wineinstall? If I do run wineinstall, I do it against my first impulse so to speak, and then I keep wondering why the heck couldn't they just stick to the standard method.
We can certainly improve the documentation to make it clear that people who know what they are doing should use configure;make and that there's nothing magical about wineinstall that would require them to use it. Patches welcome. -- Alexandre Julliard julliard(a)winehq.org
On Fri, 18 Jun 2004 17:05:49 -0700, Alexandre Julliard wrote:
Maybe Linux users in general know how to run configure (though I doubt that), but that's definitely not true for Wine users IMO; most of them come straight from Windows, and Wine is often the first time ever they build something from source.
I think the real issue here is not configure vs wineinstall, it's "why are these users building Wine from the source at all?". They are not developers, so therefore the answer must be either: 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. (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. autopackage would be ideal for this, but it's currently not at version 1.0 which should be factored into any evaluation of such installers. Also, Wine has virtually no core dependencies so you wouldn't gain much (apart from the various nice graphical frontends) over Loki Setup for Wine. Has anybody investigated this? Does anybody want to? I can help with any binary portability questions people have. thanks -mike
(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 think we're doing too badly with the current packages -- over 85% of people go for them. Having a distro-neutral binary packages would be good, and it may shave off another 5% or so of the people who do go for source downloads. The main problem however is that Wine is rapidly changing, and there is a need to build from CVS. No amount of packaging the official releases will solve that problem. But a distro-neutral might, because it makes it feasible to provide automated nightly build on SF, just like we do with winetest. Such a package can take care to avoid conflicts with already installed .rpms, etc., stuff that wineinstall is doing right now. So, what about a autopackage package? :) -- Dimi.
On Sat, 2004-06-19 at 09:54 -0400, Dimitrie O. Paun wrote:
I don't think we're doing too badly with the current packages -- over 85% of people go for them. Having a distro-neutral binary packages would be good, and it may shave off another 5% or so of the people who do go for source downloads.
You're forgetting all the people who pull from CVS. I don't know the figures (Jeremy?) but I'd be willing to bet traffic from CVS is enormous. In fact we have a mirror don't we? Most projects don't.
The main problem however is that Wine is rapidly changing, and there is a need to build from CVS. No amount of packaging the official releases will solve that problem. But a distro-neutral might, because it makes it feasible to provide automated nightly build on SF, just like we do with winetest. Such a package can take care to avoid conflicts with already installed .rpms, etc., stuff that wineinstall is doing right now.
So, what about a autopackage package? :)
Yes, I can do this. In fact we're already running nightly builds of the Inkscape vector graphics editor on navi, I could do the same for Wine. This might take some time though. For starters I'd have to fix and resubmit my binary relocatability patch. Last time I checked apbuild had nasty interactions with winebuild too (apbuild works partly by injecting inline assembly pseudo-ops into the code as it's compiled) so that'd need to be fixed as well. thanks -mike
Mike Hearn <mike(a)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(a)winehq.org
On Sat, 19 Jun 2004 10:37:54 -0700, Alexandre Julliard wrote:
d) They need something that isn't part of the standard packages (for instance BiDi support).
Is there a reason that can't be dlopened too? relaytool makes it much less hassle to write dlopened code.
e) They want to report a crash and need debug symbols to get a valid backtrace.
Red Hat have developed a neat solution for this, the latest binutils can split debug symbols into a separate set of files so you can just install debuginfo packages and gdb will automatically use them.
f) They want to try a patch that someone sent them.
How often does that occur, really? I bet about 1% of our users actually do this.
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.
I wouldn't say not supposed to do, but rather that they shouldn't *have* to do it.
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.
Yes, I agree that both routes should be as easy as possible :) I just think we should start telling users who are building from source for no real reason to use binaries instead. thanks -mike
Mike Hearn <mike(a)navi.cx> writes:
Is there a reason that can't be dlopened too? relaytool makes it much less hassle to write dlopened code.
libicu can't be dlopened thanks to their idiotic versioning scheme.
f) They want to try a patch that someone sent them.
How often does that occur, really? I bet about 1% of our users actually do this.
Given the size of our user base even 1% is a lot of people...
Yes, I agree that both routes should be as easy as possible :) I just think we should start telling users who are building from source for no real reason to use binaries instead.
Why? Why would you need a real reason to build from source? Of course if they have trouble doing that, we may suggest using binaries instead, but I don't see why using binaries has to be some sort of official policy. On the contrary, I think we should encourage as many people as possible to build the source, that's the best way to find compilation problems on strange setups. -- Alexandre Julliard julliard(a)winehq.org
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.
On June 19, 2004 01:37 pm, Alexandre Julliard wrote:
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.
Excellent, I'm glad this was said. One only has to look at the swing away from binary-distributions as a case in point - people *want* to eliminate unknown layers of patches, packaging, and divergence from the "real" thing. The original source, as distributed from the project itself, is the only sure way to get the same version of the code that is used (and thus, tested) by its authors. It is also the only way to know it tried to adapt itself appropriately to your system. Anything else involves a certain blind faith in the black-magic of distribution patching by people who are usually *not* authors of the upstream packages. Moreover, unless you pay for commercial support then you are pretty much obliged to use the unmodified upstream code if you want to have a meaningful discussion with other users/devs about problems or questions you encounter. Hardly any win32 application runs 100% perfectly under Wine (hell, the same can be said on MS-Windows), and Wine is not yet a complete work (again, a shared characteristic with the "reference implementation"). Under these circumstances, the path of least resistance is surely to *encourage* users to be singing out of the same hymn book as the development community? I've tried binary wine packages on a few occasions and *always* had major problems. Wine, and more importantly the things people need to do with it, are not yet at the point where binary packages can just drop-and-go and maintain a clean separation between users and developers. In this respect, I find the Wine build system extremely impressive. autoconf et al are not the kindest of tools and Wine has no shortage of environmental challenges, yet the source tree seems to be very solid and clean base for people to work with. Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
On Sat, 19 Jun 2004 15:01:31 -0400, Geoff Thorpe wrote:
Excellent, I'm glad this was said. One only has to look at the swing away from binary-distributions as a case in point - people *want* to eliminate unknown layers of patches, packaging, and divergence from the "real" thing.
The only popular source only distro is Gentoo, and if you saw the mess they made of the Wine ebuilds you would not say this. Binaries don't imply forking anyway.
It is also the only way to know it tried to adapt itself appropriately to your system.
Why? Wine detects nearly everything at runtime, even very system specific things (ie things users basically cannot change) like which threading system is in use.
In this respect, I find the Wine build system extremely impressive. autoconf et al are not the kindest of tools and Wine has no shortage of environmental challenges, yet the source tree seems to be very solid and clean base for people to work with.
Yep, the Wine build system is one of the easiest ones I've encountered, probably because it only uses autoconf and not automake or libtool. thanks -mike
On June 19, 2004 03:24 pm, Mike Hearn wrote:
On Sat, 19 Jun 2004 15:01:31 -0400, Geoff Thorpe wrote:
Excellent, I'm glad this was said. One only has to look at the swing away from binary-distributions as a case in point - people *want* to eliminate unknown layers of patches, packaging, and divergence from the "real" thing.
The only popular source only distro is Gentoo, and if you saw the mess they made of the Wine ebuilds you would not say this. Binaries don't imply forking anyway.
I didn't mean with respect to Wine, I meant in general - and as it happens, I use gentoo and haven't even considered trying to invoke their wine ebuild :-) Also, I wasn't just referring to Linux - I know a number of people through work who've found the simple rigour of FreeBSD/ports a breath of fresh air after battling with fungal "enterprise" linux distributions and the bloated, untrackable, prepackaged messes they have become.
It is also the only way to know it tried to adapt itself appropriately to your system.
Why? Wine detects nearly everything at runtime, even very system specific things (ie things users basically cannot change) like which threading system is in use.
Well that won't necessarily help you if wine was built against headers/libs (X, sound, libc, ...) that have incompatibilities with what's on the host at run-time. I'm not saying this *is* a problem, but if you're using a prepackaged binary, you certainly can't rule it out when things go berzerk. If you configure, compile, install, and run all on the same system, this sort of thing is less likely - and moreover the configure script may actually have a chance to alert you to problems the easy way (eg. "I'm going no further until you upgrade that buggy <foo> crap"). I'm not saying this is a general rule for anything and everyone, far from it. For some people and some tools, prepatched / preconfigured / precompiled / prepackaged releases are a god-send. But as Alexandre intimated, I think Wine is (for now) one of those tools where it is very useful for people to be able to go directly to the source without having to learn screeds of obscure build cruft. Anyway, isn't this how people get interested in open source programmning anyway? ;-)
In this respect, I find the Wine build system extremely impressive. autoconf et al are not the kindest of tools and Wine has no shortage of environmental challenges, yet the source tree seems to be very solid and clean base for people to work with.
Yep, the Wine build system is one of the easiest ones I've encountered, probably because it only uses autoconf and not automake or libtool.
It's quite astonishing considering the breadth of crud that has to be covered; binary loading (16-bit, 32-bit, etc), sound, video, memory management, threading and locking models, signals, IPC, [etc]. And I think there's more to that than just avoiding automake/libtool :-) Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
On Sat, Jun 19, 2004 at 03:01:31PM -0400, Geoff Thorpe wrote:
On June 19, 2004 01:37 pm, Alexandre Julliard wrote:
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.
Excellent, I'm glad this was said. One only has to look at the swing away from binary-distributions as a case in point - people *want* to eliminate unknown layers of patches, packaging, and divergence from the "real" thing. The original source, as distributed from the project itself, is the only sure way to get the same version of the code that is used (and thus, tested) by its authors. It is also the only way to know it tried to adapt itself appropriately to your system. Anything else involves a certain blind faith in the black-magic of distribution patching by people who are usually *not* authors of the upstream packages. Moreover, unless you pay for commercial support then you are pretty much obliged to use the unmodified upstream code if you want to have a meaningful discussion with other users/devs about problems or questions you encounter.
Hardly any win32 application runs 100% perfectly under Wine (hell, the same can be said on MS-Windows), and Wine is not yet a complete work (again, a shared characteristic with the "reference implementation"). Under these circumstances, the path of least resistance is surely to *encourage* users to be singing out of the same hymn book as the development community? I've tried binary wine packages on a few occasions and *always* had major problems. Wine, and more importantly the things
Did you report those problems? For SUSE packages I would like to know. Btw, my package mostly does ./configure make make install The number of to-patche things (for automatic configuration) has been reduced greatly over the last years. Ciao, Marcus
participants (6)
-
Alexandre Julliard -
Dimitrie O. Paun -
Geoff Thorpe -
Marcus Meissner -
Mike Hearn -
Vincent Béron