Bugzilla – Full Text Bug Listing
| Summary: | Incorrect dependencies in epp.packages.linuxtools | ||
|---|---|---|---|
| Product: | [Technology] EPP | Reporter: | Thomas Hallgren <thomas> |
| Component: | linuxtools-package | Assignee: | Project Inbox <epp.packager-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, jonah, Kenn.Hussey, michal.ruza, miles.daffin, overholt |
| Version: | unspecified | ||
| Target Milestone: | 1.3.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
So ... what's to be done here? I can't see rebuilding the existing repository, due to too much risk of regressing something else. Is there a "mini repository" that could be added to our composite repo so "make it right"? If not, I suspect this will be a "won't fix" unless anyone has any other suggestions. How can this problem be avoided in future? Can improvements be made to aggregator so would be caught or, warned about, in future? Or, improvements in processes or tests? Is it just a matter of the "owning" project to do more testing? (In reply to comment #1) > How can this problem be avoided in future? > > Can improvements be made to aggregator so would be caught or, warned about, in > future? Or, improvements in processes or tests? > This would have been detected by the aggregator if the epp repository was part of the Helios aggregation. It wasn't. Instead, it was added to the Helios Composite after the fact. Perhaps this can be done differently with Indigo? IIRC, Markus created the EPP package IU for us originally. We do indeed only want the EPP package to be available for x86 and x86_64 Linux GTK due. If I'm reading your comments correctly, this means that we should "add a corresponding filter to the 'epp.package.linuxtools' IU so that it, as a whole, is discriminated the same way as the feature that it requires"? (In reply to comment #3) > ... this means that we should "add a corresponding > filter to the 'epp.package.linuxtools' IU so that it, as a whole, is > discriminated the same way as the feature that it requires"? Yes. With that objective, that would be the best solution. (In reply to comment #4) > (In reply to comment #3) > > ... this means that we should "add a corresponding > > filter to the 'epp.package.linuxtools' IU so that it, as a whole, is > > discriminated the same way as the feature that it requires"? > > Yes. With that objective, that would be the best solution. It's not clear to me how to proceed. Is this something Markus/someone else must do when the metadata is created or is it something I can do? I did some changes, see the inclusion of the linuxtools feature below: + org.eclipse.epp.allpackages.indigo.feature ---+ includes features ---+---+ org.eclipse.epp.package.common.feature ---+---+ org.eclipse.epp.package.cpp.feature ---+---+ ... ---+---+ org.eclipse.epp.package.linuxtools.feature (now with os="linux" arch="x86,x86_64") + org.eclipse.epp.package.linuxtools.feature itself with os="linux" ws="gtk" arch="x86,x86_64" (unchanged) ---+ includes bundle ---+---+ org.eclipse.epp.package.linuxtools (without any filters) ---+ includes product definition ---+---+ epp.product (unfortunately without any filters) ---+---+---+ defines the epp.package.linuxtools IU Maybe the change of the top-level EPP feature (org.eclipse.epp.allpackages.indigo.feature) that is used in the Buckminster build is enough, but I am a bit sceptical. Unfortunately it is not possible to add any filters to the product definition in the epp.product configuration file. Any thoughts? Can we do something with a p2.inf? This has been fixed a long time ago and now linux tools are part of the CPP package. |
The epp.package.linuxtools IUs found in the Helios repository all have a broken requirement generated for org.eclipse.epp.package.linuxtools.feature.feature.group. The requirement is stated like this: <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.epp.package.linuxtools.feature.feature.group' range='[1.3.2.20110301-1807,1.3.2.20110301-1807]'/> and while it looks correct at first, it is actually broken. The targeted feature is filtered with: (&(osgi.os=linux)(osgi.ws=gtk)(|(osgi.arch=x86)(osgi.arch=x86_64))) and unless the requirement also has this filter, it will render the IU uninstallable on environments that are discriminated by the filter. This is because p2 will see the unfiltered requirement but it will be unable to resolve it due to the filter on the IU that is expected to fulfill it. I can see two solutions to this problem. Either add a corresponding filter to the 'epp.package.linuxtools' IU so that it, as a whole, is discriminated the same way as the feature that it requires. Or, add a corresponding same filter only to the requirement. Doing the latter means that the 'epp.package.linuxtools' can still be installed on all platforms but the required feature will be left out. While this bug might seem like a minor problem (the IU will not be considered in the p2 installer since it's name doesn't end with 'feature.group'), the inconsistency does have ramifications that goes beyond that use case. For instance, the Helios repository as a whole cannot be mirrored using a validating mirroring tool such as the b3.aggregator without adding special exceptions.