Description of problem: It's not possible to install the agent when following packages are already installed: EAP7: eap7-keycloak-adapter eap7-keycloak-saml-adapter EAP6: keycloak-adapter-eap6 keycloak-saml-adapter-eap6 This issue is visible for following repositories: jb-eap-7.0-for-rhel-7-server-rpms jb-eap-6-for-rhel-7-server-rpms jb-eap-6.4-for-rhel-7-server-rpms Version-Release number of selected component (if applicable): eap7-middleware-manager-agent-1.0.0-4.CR5_redhat_1.1.ep7.el7.noarch.rpm and middleware-manager-agent-eap6-1.0.0-4.CR5_redhat_1.1.ep6.el7.noarch.rpm How reproducible: Always Steps to Reproduce: 1. install everything from one of the repositories above (installing only keycloak packages should be sufficient) yum -y install '*' 2. try to install the agent: yum install eap7-middleware-manager-agent-1.0.0-4.CR5_redhat_1.1.ep7.el7.noarch.rpm Actual results: Transaction check error: file /opt/rh/eap7/root/usr/share/wildfly/modules/system/add-ons from install of eap7-middleware-manager-agent-0:1.0.0-4.CR5_redhat_1.1.ep7.el7.noarch conflicts with file from package eap7-keycloak-adapter-0:2.5.5-1.Final_redhat_1.1.ep7.el7.noarch file /opt/rh/eap7/root/usr/share/wildfly/modules/system/add-ons from install of eap7-middleware-manager-agent-0:1.0.0-4.CR5_redhat_1.1.ep7.el7.noarch conflicts with file from package eap7-keycloak-saml-adapter-0:2.5.5-1.Final_redhat_1.1.ep7.el7.noarch Expected results: Not sure if this is expected behavior or not. The agent should be either installed correctly or it should be documented that it's not possible to have those keycloak packages on the system when installing the agent.
This sounds like an RPM packaging issue. The failure appears to be related to the "add-ons" directory (/modules/system/add-ons). The agent stores its binaries in the WildFly add-ons directory (which doesn't exist out of box, the agent RPM probably creates that directory). But if you have other add-ons packages (which sounds like is what the keycloak stuff does as well) then it sounds like the "add-ons" directory is causing a conflict. The agent files themselves probably don't conflict because they exist in their own add-ons subdirectory "hawkular-agent" (and it would be odd if keycloak puts stuff in that named directory).
(In reply to John Mazzitelli from comment #1) > But if you have other add-ons packages (which sounds like is what the > keycloak stuff does as well) then it sounds like the "add-ons" directory is > causing a conflict. The agent files themselves probably don't conflict > because they exist in their own add-ons subdirectory "hawkular-agent" (and > it would be odd if keycloak puts stuff in that named directory). Yes, 'rpm -ql eap7-keycloak-adapter | grep add-ons' shows that keycloak uses /opt/rh/eap7/root/usr/share/wildfly/modules/system/add-ons/keycloak
(In reply to Filip Brychta from comment #2) > (In reply to John Mazzitelli from comment #1) > > > But if you have other add-ons packages (which sounds like is what the > > keycloak stuff does as well) then it sounds like the "add-ons" directory is > > causing a conflict. The agent files themselves probably don't conflict > > because they exist in their own add-ons subdirectory "hawkular-agent" (and > > it would be odd if keycloak puts stuff in that named directory). > > Yes, 'rpm -ql eap7-keycloak-adapter | grep add-ons' shows that keycloak uses > /opt/rh/eap7/root/usr/share/wildfly/modules/system/add-ons/keycloak So what I suspect is happening is the rpms are not expecting other "things" to be in add-ons. If an rpm expects to "own" add-ons and doesn't expect that location to already exist, that could explain the conflict. The rpms must not bomb if add-ons already exists and has other subdirectories in it - because that's what add-ons is for - it can contain many different add-ons. No one add-on owns that "add-ons" directory.
All the files should e able to own the add-ons directory. This is important for RPM to determine when to create and when to remove it. There must be an error in the ownership or file (dir) permissions of oe of the packages. These must match in all packages that own it.
There was a permission mismatch on the add-ons directory between the two rpms. Updated EAP 7 build: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=565533 Updated EAP 6 build: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=565544
(In reply to Paul Gier from comment #5) > There was a permission mismatch on the add-ons directory between the two > rpms. There was a regression, as the fix also changed the permissions on the %doc. I've updated the specs in git to leave the standard permissions on the %doc.