I'm running an up-to-date CentOS 6.5 and I wanted to install eclipse so I went to System->Adminitration->Add/Remove Software and installed eclipse-cdt-1:7.0.1-4.el6 and a bunch of dependent packages.>From the eclipse help menu I see that this is version 3.6.1. According to wikipedia this is a eclipse Helios which was released in June of 2010.My question is why is this so far out of date? My understanding was that CentOS was generally about a year out-of-date. I must confess that I don't know where I got that idea from and it is no doubt, wrong but 3 1/2 years out-of-date seems excessive. Is it just a packaging issue and whoever makes the RPMs hasn't made a new one? If I try to check for updates from inside eclipse, I get various failures for non-existant sites and dependency conflicts. Can anyone explain the situation and maybe shed some light on the history of how we got to this point.>From what I have read so far the solution is to ignore the rpms and install from the eclipse site.Thanks, Steve
2013/12/26 Steve <zephod at cfl.rr.com>> I'm running an up-to-date CentOS 6.5 and I wanted to install eclipse so I > went to System->Adminitration->Add/Remove Software and installed > eclipse-cdt-1:7.0.1-4.el6 and a bunch of dependent packages. > > >From the eclipse help menu I see that this is version 3.6.1. According to > wikipedia this is a eclipse Helios which was released in June of 2010. > My question is why is this so far out of date? My understanding was that > CentOS was generally about a year out-of-Well, it is way that RHEL/Centos works. Maybe you should use Fedora instead of it or roll your own eclipse package for Centos? -- Eero
On 12/26/2013 10:50 AM, Steve wrote:> My understanding was that CentOS was generally about a year out-of-date.When a major RHEL version is released, the major.minor versions of most all components are frozen for the life cycle of that major release, this ensures package compatability, so if something is released for EL6 it can expect to run with any EL6.x update. major EL versions have a 5-7 year support life cycle, we're nearing the back side of that for EL6, which came out in 2010. RHEL7 is still in beta (and running a year or so later than I would have expected according to their historical release cycle). -- john r pierce 37N 122W somewhere on the middle of the left coast
The usual explanations about why version numbers are what they are in CentOS apply. However, taking off my systems hat for a minute and put on my software development hat, in the case of Eclipse I wouldn't suggest using the one available via RPM anyway. During software development just as you want to control the versions of your jars, libraries, etc of your application stack, you should probably independently control the versions of your IDE, as changing IDE versions is as intrusive as changing library versions, and it is rarely convenient to schedule that kind of change concurrently with an OS upgrade. So in the case of Eclipse, I would worry less about why the CentOS one is out of date and instead pick a relatively recent version, download the *.gz, have the developers extract it to local disk, and run it that way. Slightly OT, but while you're at it, I'd suggest also keeping your workspaces separate for each Eclipse version and project, thus something like: ~/src/eclipse-workspaces/indigo32/project1 ~/src/eclipse-workspaces/juno64/project2 ~/src/eclipse-workspaces/juno64/project3 Plus, Eclipse is always better with a workspace that is local disk. Devin