Bug 718009

(In reply to comment #0)
> Update to 7.0.1-7 provides "strange" versions of cdt-autotools and cdt-libhover
> plugins (labelled: 201105xxx). Gcov and gprof plugins depend on 201102xx
> versions of aforementioned plugins. 201105xx releases are not to be found in
> linuxtools project repository
> (http://download.eclipse.org/technology/linuxtools/), so I wonder where these
> do come from. Re-installing gcov and gprof manually via eclipse will not work
> as well as libraries that were put into place by Fedora cannot be, for some
> strange reasons, overridden by user. Please provide a workaround or correct
> this bogus update anyhow. Thanks in advance.

First of all, the numbers you are referring to are date qualifiers.  They are in addition to the version numbers and are generated/specified at build time.  No plugin/feature should ever require the date qualifier and gcov/gprof are no exception.  The qualifier is there to allow sequential builds to be ordered with respect to updates.  This is how nightly updates work.  They don't up the release number every night, but instead the qualifier goes up so Eclipse will update the newer versions of the packages if you choose to download from the nightly site.

Now, in addition, neither gcov nor gprof require libhover or autotools.

The gprof/gcov plugins are not supplied by a Fedora package.  They must be fetched via the Helios update site or the Linux Tools update sites.  This is a separate update mechanism that may or may not be in sync with what is in Fedora.  If the plugins are built with later versions of Eclipse or CDT and are not explicitly specifying required versions, then there is nothing that the CDT build can do.

Now, the version of Eclipse used in the latest Helios update site (3.6.2) is beyond the one currently in F14 (3.6.1) which was also used to build the eclipse-cdt package.  That said, that is probably the reason this isn't working.  I was able to reproduce the problem and looking in the gcov plugins, there are no versions specified for required bundles.  The plugins do load, but don't run.

My suggestion for a workaround would be to download an older Linux Tools release by using an archived release from: http://archive.eclipse.org/technology/linuxtools/  Unfortunately they are not tagged with the Linux Tools release number but you can find out easily by clicking on each build.

(In reply to comment #1)
> (In reply to comment #0)
> > Update to 7.0.1-7 provides "strange" versions of cdt-autotools and cdt-libhover
> > plugins (labelled: 201105xxx). Gcov and gprof plugins depend on 201102xx
> > versions of aforementioned plugins. 201105xx releases are not to be found in
> > linuxtools project repository
> > (http://download.eclipse.org/technology/linuxtools/), so I wonder where these
> > do come from. Re-installing gcov and gprof manually via eclipse will not work
> > as well as libraries that were put into place by Fedora cannot be, for some
> > strange reasons, overridden by user. Please provide a workaround or correct
> > this bogus update anyhow. Thanks in advance.
> 
> First of all, the numbers you are referring to are date qualifiers.  They are
> in addition to the version numbers and are generated/specified at build time. 
> No plugin/feature should ever require the date qualifier and gcov/gprof are no
> exception.

Thx for the explanation, didn't know that.


> 
> Now, in addition, neither gcov nor gprof require libhover or autotools.
> 

Eclipse update mechanism tries to install them, furthermore it complains about their versions, so I assume they are somehow required.

> The gprof/gcov plugins are not supplied by a Fedora package. 

I've already "reported" that. Please take a look at: https://bugzilla.redhat.com/show_bug.cgi?id=718024 .

> They must be
> fetched via the Helios update site or the Linux Tools update sites.  This is a
> separate update mechanism that may or may not be in sync with what is in
> Fedora.  If the plugins are built with later versions of Eclipse or CDT and are
> not explicitly specifying required versions, then there is nothing that the CDT
> build can do.
> 
> Now, the version of Eclipse used in the latest Helios update site (3.6.2) is
> beyond the one currently in F14 (3.6.1) which was also used to build the
> eclipse-cdt package.  That said, that is probably the reason this isn't
> working.  I was able to reproduce the problem and looking in the gcov plugins,
> there are no versions specified for required bundles.  The plugins do load, but
> don't run.
> 

It may be reasonable to update F14 package then. Anyway, these plugins'd worked before I updated Eclipse. So I believe that your explanation might not be 100% correct. The situation here is that plugins stopped working right after this update. When I tried to reinstall them via Eclipse mechanism, installation failed due to unsatisfied dependencies (cdt.libhover and cdt.autotools), which are, all in all, installed. Now, ...


> My suggestion for a workaround would be to download an older Linux Tools
> release by using an archived release from:
> http://archive.eclipse.org/technology/linuxtools/  Unfortunately they are not
> tagged with the Linux Tools release number but you can find out easily by
> clicking on each build.

... this also does not work. I downloaded R201102 zip (mainly because it matched what installer seemed to expect) and tried to install - it complained that there  was newer version of autotools/libhover. To sum it up:
- plugins in question stopped working after fedora update (they worked flawlessly before)
- if you use inuxtools project update site to reinstall gprof and gcov you get:
An error occurred while collecting items to be installed
session context was:(profile=PlatformProfile, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.autotools,2.0.0.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.autotools.core,1.0.1.201102162051
No repository found containing: org.eclipse.update.feature,org.eclipse.linuxtools.cdt.autotools,2.0.1.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.autotools.ui,1.0.1.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.autotools_docs,2.0.2.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.libhover,1.0.3.201102162051
No repository found containing: org.eclipse.update.feature,org.eclipse.linuxtools.cdt.libhover,0.2.0.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.libhover.glibc,1.0.1.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.libhover.library_docs,1.0.1.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.libhover.libstdcxx,1.0.0.201102162051

Now, this is all wrong because,according to you, except for this date qualifier, cdt packaging has them

- if you install from older release archive you get (201102162051 - to be precise) roughly the same output:
An error occurred while collecting items to be installed
session context was:(profile=PlatformProfile, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.autotools,2.0.0.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.autotools.core,1.0.1.201102162051
No repository found containing: org.eclipse.update.feature,org.eclipse.linuxtools.cdt.autotools,2.0.1.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.autotools.ui,1.0.1.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.autotools_docs,2.0.2.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.libhover,1.0.3.201102162051
No repository found containing: org.eclipse.update.feature,org.eclipse.linuxtools.cdt.libhover,0.2.0.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.libhover.glibc,1.0.1.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.libhover.library_docs,1.0.1.201102162051
No repository found containing: osgi.bundle,org.eclipse.linuxtools.cdt.libhover.libstdcxx,1.0.0.201102162051

- if you try to update/downgrade/do whatever it needs to autotools you get either:
Your original request has been modified.
  "Autotools support for CDT (Incubation)" will be ignored because a newer version is already installed. 

or

Your original request has been modified.
  Autotools support for CDT (Incubation) will be ignored because it is already installed, and updates are not permitted.

All this suggests that the version Fedora update has pushed is somewhere between old one (from zip) and new one (from update site).

You're not trying to install all of Linux Tools are you?  You only want to specify gcov and/or gprof.  The Eclipse update manager is not aware of what is installed via rpm.  If you specify packages you already have installed via rpm, then problems will occur.

It is a messy situation because /usr directories are owned by root and the user has to modify the home directory which the rpm installation cannot do.

The best solution to this particular problem is to create a Fedora version of these plugins which you have requested.

(In reply to comment #3)
> You're not trying to install all of Linux Tools are you?  You only want to
> specify gcov and/or gprof.  

As far as I can tell no - errors I pasted in the comment above are shown after selecting these two (in an act of desperation I tried to reinstall autoconf plugin but that attempt failed as well, I pasted errors)

> The Eclipse update manager is not aware of what is
> installed via rpm.  If you specify packages you already have installed via rpm,
> then problems will occur.
> 
> It is a messy situation because /usr directories are owned by root and the user
> has to modify the home directory which the rpm installation cannot do.
> 
> The best solution to this particular problem is to create a Fedora version of
> these plugins which you have requested.

Probably. Maybe someone can take it from here and package these plugins - I am certainly not any RPM god to try it myself. Anyway, should I wait for this, let's call it that, bug to be fixed (if there is anything I can do to help then I can surely try) or is it how messing with Eclipse ends and nothing more can be done about this? :-) For now I've reverted to using gcov from terminal but I feel that this is step backward :-)

Jeff, can you reproduce this situation?  I just tried in Fedora 15 (on x86_64) and I'm able to install the Linux Tools 0.8 GProf and GCov plugins on top of the eclipse-cdt (eclipse-cdt-7.0.2-1.fc15.x86_64) RPM without any problems.

This is probably caused by: https://bugzilla.redhat.com/show_bug.cgi?id=718277 from what I observed (at least part of the problem is fixed by changing modules config file)

This bug is against Fedora 14. I'm closing it now please reopen if it still can be reproduced with supported Fedora version.