blob: 9f4b91d3a4f70daa902553a483f271e673e6a18c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel Kreuter wrote:
<blockquote
cite="mid:AANLkTik_goSz3Rybp0M0p5YJZ94phafiKWPhPNjvLRqh@mail.gmail.com"
type="cite"><br>
I don't agree with you at that point. I always take the tarball from <a
moz-do-not-send="true" href="http://eclipse.org">eclipse.org</a> (for
eclipse) or <a moz-do-not-send="true" href="http://netbeans.org">netbeans.org</a>
(for netbeans) instead of the one's of repository provided by the
distro.<br>
The reason is quite simple, the one's mentioned above are newer than
the one's in the repos (often, not always but everywhere i looked for
it, it was so)<br>
<br>
But there may be people who will first look in rpmdrake or urpmi that's
right, but not everybody.<br>
</blockquote>
<br>
Well, I didn't say *everybody*, I was referring to newer users who
might actually do what we tell them to :-)<br>
<br>
The problem is that there is a very high probability that anyone who
installs from an RPM will then install plugins directly. Given that, I
would question even packaging the base product as an RPM.<br>
<br>
Then again, there's the concern about whether an RPM-provided package
may provide something a tarball does not, or vice-versa. For example,
the MDV Java RPMs play all sorts of games with /etc/alternatives and
don't (I think) set environment variables like JAVA_HOME. This means
that tarball installs of things like Ant need manual tweaking to work
correctly with an RPM-based JDK. The RPM-based Ant has wrapper scripts
which depend on the /etc/alternatives stuff and determine JAVA_HOME on
the fly.<br>
</body>
</html>
|
