Bugzilla – Full Text Bug Listing
| Summary: | b3 aggregator includes too much | ||
|---|---|---|---|
| Product: | [Technology] CBI | Reporter: | David Williams <david_williams> |
| Component: | CBI p2 Repository Aggregator | Assignee: | Project Inbox <b3.aggregator-inbox> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | thomas |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
David Williams
The exclusion rules wouldn't help in this case since it works at feature level. It doesn't really affect what's available to the planner and it doesn't interfere with the planning at all. The planner does it's job. It comes up with a plan that will allow everything to be installed as one big coherent feature. That means that it considers the old unwanted plug-ins the best match. The only way to get rid of that is to convince it that something else is preferred. One way to do that is to let a feature have a hard requirement to another (preferred) bundle that exports the common packages. Apparently that is not the case today. A more advanced approach would be to express a negation that excludes the unwanted bundles from the plan. Today that could be done in a p2.inf file of a feature. I can see how that could become a future enhancement to the aggregator. We could add it as a negation requirement on the generated top level feature. At present I'm afraid I have no simple solution. Given that the next release is RC4, I'm a bit reluctant starting new experiments with the aggregator. Thanks Thomas. I certainly agree with no experiments. This was noticed only because it was unsigned ... which by itself would not be "bad" ... the only bad thing would be if there was some combination of things (or "select all") that caused this to be installed ... which would probably not be what anyone would want. As a work around for Helios, is there any chance we could "post process" the repo, and use p2.remove task to remove 1 or 2 artifacts that are known to be incorrect? Or would that risk leaving the repo in an inconsistent/incomplete state? (In reply to comment #2) > As a work around for Helios, is there any chance we could "post process" the > repo, and use p2.remove task to remove 1 or 2 artifacts that are known to be > incorrect? Or would that risk leaving the repo in an inconsistent/incomplete > state? I'm afraid that the answer is very likely yes. The planner does have a reason for the inclusion. If that reason is purely based on optional requirements, then it will be OK. If not, well, then there's a problem. The best fix is probably to go to the source. Would it be possible for the contributor to refrain from making the unwanted bundles available to the aggregation?
>
> The best fix is probably to go to the source. Would it be possible for the
> contributor to refrain from making the unwanted bundles available to the
> aggregation?
Would that be by removing it from the uber repo where it currently is? Maybe. (or, moving to some special "old" repo not linked in).
Yet another case adding doubt to the proposition
that "repos are forever", eh? :)
(In reply to comment #4) > Yet another case adding doubt to the proposition > that "repos are forever", eh? :) It shows that there's more then one truth. In some situations it's good to have historical data while in others, it really gets in the way. I think this needs to be discussed in more depth. We need to break things down to pros and cons for different use-cases and then make things available based on what we conclude. The current situation is not good. I'm closing this as invalid since I don't see how we can improve the situation with the aggregator. Concrete proposals are welcome as separate enhancement requests. [Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. No change to assignee for resolved and verified bugs.] |