On Mon, 2006-11-09 at 21:25 -0600, Aaron Luchko wrote:
<snip>
One minor nitpick with these packages though, the update sites listed
in
the update manager were from 3.1, I had to export the update sites from
an upstream download in 3.2 and import them into this version to be able
to install 3.2 updates. I think the problem is in
/usr/share/eclipse/features/org.eclipse.sdk_3.2.0.v20060609m-GpOJnQq-7es-zhF/feature.xml
a diff with upstream shows
<url>
- <update label="%updateSiteName"
url="http://update.eclipse.org/updates/3.1"/>
- <discovery label="%updateSiteName"
url="http://update.eclipse.org/updates/3.1"/>
+ <update label="%updateSiteName"
url="http://update.eclipse.org/updates/3.2"/>
+ <discovery label="%updateSiteName"
url="http://update.eclipse.org/updates/3.2"/>
+ <discovery label="%secondaryUpdateSiteName"
url="http://download.eclipse.org/callisto/releases"/>
</url>
Thanks. Here's the bug if you're interested:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205933
I looked into this the other day and I think we can get rid of the
script if I re-organize files list. Expect a fix in the next couple of
days.
On a side, and decidedly unrelated to java, note it would nice if
there
was some supported way of installing different versions of packages with
yum other than installing from rawhide and possibly needing a massive
pile of other dependencies. Something like a fedora-beta or yum
--getVersion flag that lets someone get a development version of the
package (like eclipse 3.2) with a minimal set of dependencies. I just
think of the number of times I've needed to install a fairly stable beta
of some application to my home directory because even if there was an
rpm there would be too many broken dependencies in updating it.
Of course, I say this as someone who wouldn't have to do the packaging
or chase down bugs popping up in all the different configurations :)
Another problem is that packages compiled with a newer compiler will not
always work on the older system.
Ben