Dimitrie O. Paun
dpaun at rogers.com
Fri Jun 18 15:01:39 CDT 2004
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
-- 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?
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.
More information about the wine-devel