[ https://issues.jboss.org/browse/JBDS-4257?page=com.atlassian.jira.plugin.... ] Václav Kadlčík commented on JBDS-4257: -------------------------------------- {quote}You want the RPM to not "provide" the plugins that are contained in the RPM{quote} Yes {quote}including not providing all the stuff from jbosstools, the devstudio branding plugins{quote} They can be declared as Provides, I mentioned that explicitly. But, in the end, it doesn't matter, because AFAIK there are no RPMs with matching Requires, hence YUM wouldn't care. {quote}all the 3rd party stuff from Eclipse Orbit which is needed for the jbosstools/devstudio plugins and which are not available from other rh-eclipse46-* packages{quote} The same situation. They can be declared in Provides but there's no use case for that at this moment. They just add maintenance burden - you should react on new Provides in all the RHSCL Eclipse RPMs and blacklist in Devstudio. Please keep in mind that the RPM Requires/Provides declarations are just about the RPM dependency management, in practical terms, how YUM would resolve dependencies. I suppose we don't want Devstudio to serve as a dependency therefore its Provides should be as minimal as possible. Maybe it's been lost a bit in the discussion, but the original problem Lukáš reported was "rh-eclipse46-devstudio is installed as dependency when installing rh-eclipse46". {quote}How would I do that? Can you suggest a PR for this spec file?{quote} I'm sorry, not really. At a first glance, we'd need something subtler than java_common_find_provides_and_requires but please ask Mat or other dev. {quote}By the way, re: "Rh-eclipse46 provides 4 packages, devstudio provides 539 packages" ... rh-eclipse46 is a meta-package which just wraps other packages. Maybe you should compare rh-eclipse46-devstudio to rh-eclipse46-base? or to rh-eclipse46-eclipse-cdt-native ?{quote} (Lukáš wrote that but I think I know what he meant.) rh-eclipse46-base is designed to provide dependencies, we do want it be recognized by YUM as a provider and installed as a dependency, so the comparison with Devstudio does not hold. rh-eclipse46-eclipse-cdt-native is just an intermediate, you mean "top" level RPMs like rh-eclipse46-eclipse-cdt, -pydev, -dltk, I guess? {{for i in cdt pydev dltk; do echo "= $i ="; rpm -q --provides rh-eclipse46-eclipse-$i | grep -v $i; done}} Except for org.eclipse.tools.templates.* in cdt, they are quite clean. They aren't probable to be dragged by YUM as an unwanted dependency... I can see a difference against {{rpm -q --provides -p ~/rh-eclipse46-devstudio-10.3-0.20170126.0742.el7.x86_64.rpm | grep -v jboss}}. At the end, I'd like to point out the context of the problem. It's not that big as it may seem from the discussion. To manifest, it needs several things at once: * a user has Devstudio's YUM repository enabled but Devstudio not installed * Devstudio RPM has something in Provides, let's call it X, which is served by some other RPM, too (and we prefer this other RPM as the provider) * the user installs something which needs X * YUM decides that the best provider for X is Devstudio I estimate there aren't many users affected. Moreover, the situation can be resolved manually with a few yum commands. Finally, Devstudio RPMs is getting slimmer over time (more and more relying on rh-eclipse46-base) and the automatically generated Provides are getting thinner so the problem is in slow "self-healing". In summary, we do have some problem here but of a limited impact and not getting worse. -- This message was sent by Atlassian JIRA (v7.2.3#72005)